DDD — What is Domain Driven Design?

DDD is nothing else than a new way of developing software, published by Eric Evans in 2003. Evans grouped a lot of patterns and experiences toguetter in his book: Domain-Driven Design: Tackling Complexity in the Heart of Software. The idea is described by the title itself: To develop a software based on its domain.

How is it done?

Organization:

• At first, the team needs to set a comon languange for the project. If the client is a bank for example, you will want to use the bank language. Ex: Class client, method showBalance, etc. That is called Ubiquitous Language. Along with it, you will bring everything that is in the business into the project, with apropriate identation.
• The model should be created by the whole team (architects, business especialists and developers) toguetter. That practice avoid non-implementable ideas as well as softwares that don’t fit the business intention.
• Therefore, you should divide the architecture into 4:

User Interface: The part rensponsable by the communication with the user. It should display information in addition to handling commands.

Application: Connects the Interface to the lower parts.

Domain: The business concepts and rules. This is where DDD is focused at.

Infrastructure: Technical resources of the project. It provides support to the software. Ex: Connection with databases, disk reading, etc.

Inside the Domain we will use some patterns:

• Entities: Classes of objects that need some kinf of identity. Usually, they have a life cycle, like customers, that come and go.
• Valuables: They have no identity distinction, just carry some fixed values, like strings, ints, etc.
• Aggregates: Elements encapsulated by a root class. They can only be manipulated by the root.
• Factories: They create the Aggregates. Aggregates can be really complex, so their creation should be separated.
• Services: A class that doesn’t store states. It only contains the bussiness logic.
• Repositories: Class responsable by manage the life cycle of the objects (creation, alteration and removal).
• Modules: They group classes that have a common domain. Ex: Packages in Java.

Then, refactor:

• Use what you already have to improve your code.
• Rename Classes and methods according to what they do but not showing how they do it.
• Try not to create methods that change the state of the objects. Let it for the commands.
• Create tests to validate the commands that change status.

The last, but not least:

• Map of contexts: Create delimited contexts and allocate each part of the code to the one it fits. You can make connections with those contexts, translating the terms for each one.
• Producer/Consumer: Try to have a good producer-consumer relacion. The producer needs to give the consumer the sofwtare and the consumer needs to expecify what he wants and make decisions based on what he will get by the producer.
• Shared core: That’s when two parts of the team modify the same section of the code. You should define a lot of tests to validate those modifications. This process is good to avoid duplicates.
• Anti-corruption layer: If you are using a legacy code or even a poorly written code, you should have a layer that communicate this code with your application.
• Separated ways: If the integration price is too high compared to the benefits of doing it, sometimes is better to separate the work so that the systems do not depend on each other.
• Identifying the core: You should organize the project. Take the central concepts and that is your domain. The domain is your work priority. You can even use external libraries for the border problems.

Conclusion:

After all this technical way of implementing DDD, we can say that it is a really nice way of organizing the software, defining and focusing on what are the main funcionalities of the software. DDD is a way of seeing the project as one, identifying and organizing its parts.