Domain-driven design (DDD) is an approach to developing software for complex problems by deeply connecting the implementation to an evolving model of the core business concepts. DDD is here to solve the complexity problem. Every project starts small and grows bigger and bigger, and so does its complexity.
It aims to ease the creation of complex applications by connecting the related pieces of the software into an ever-evolving model. DDD focuses on three core principles:
Focus on the core domain and domain logic.
Base complex designs on models of the domain.
Constantly collaborate with do: While many would consider this an advantage, it cannot be denied that DDD practices strongly rely on constant iteration and continuous integration in order to build a malleable project that can adjust itself when necessary. Some organizations may have trouble with these practices, particularly if their past experience is largely tied to less-flexible development models, such as the
Advantages of Domain-Driven Design
Eases Communication: With an early emphasis on establishing a common and ubiquitous language related to the domain model of the project, teams will often find communication throughout the entire development life cycle to be much easier. Typically, DDD will require less technical jargon when discussing aspects of the application, since the ubiquitous language established early on will likely define simpler terms to refer to those more technical aspects.
Improves Flexibility: Since DDD is so heavily based around the concepts of object-oriented analysis and design, nearly everything within the domain model will be based on an object and will, therefore, be quite modular and encapsulated. This allows for various components, or even the entire system as a whole, to be altered and improved on a regular, continuous basis.
Emphasizes Domain Over Interface: Since DDD is the practice of building around the concepts of domain and what the domain experts within the project advise, DDD will often produce applications that are accurately suited for and representative of the domain at hand, as opposed to those applications which emphasize the UI/UX first and foremost. While an obvious balance is required, the focus on domain means that a DDD approach can produce a product that resonates well with the audience associated with that domain.
Disadvantages of Domain-Driven Design
Requires Robust Domain Expertise: Even with the most technically proficient minds working on development, it’s all for naught if there isn’t at least one domain expert on the team that knows the exact ins and outs of the subject area on which the application is intended to apply. In some cases, domain-driven design may require the integration of one or more outside team members who can act as domain experts throughout the development life cycle.
Encourages Iterative Practices: While many would consider this an advantage, it cannot be denied that DDDpractices strongly rely on constant iteration and continuous integration in order to build a malleable project that can adjust itself when necessary. Some organizations may have trouble with these practices, particularly if their past experience is largely tied to less-flexible development models, such as the waterfall model or the like.
Ill-Suited for Highly Technical Projects: While DDD is great for applications where there is a great deal of domain complexity (where business logic is rather complex and convoluted), DDD is not very well-suited for applications that have marginal domain complexity, but conversely have a great deal of technical complexity. Since DDD so heavily emphasizes the need for (and importance of) domain experts to generate the proper ubiquitous language and then domain model on which the project is based, a project that is incredibly technically complex may be challenging for domain experts to grasp, causing problems down the line, perhaps when technical requirements or limitations were not fully understood by all members of the team.
Working of Domain Driven Design
DDD proposes to have a set of defined constructs that can be used to build models. Having these predefined elements makes it easier for both the developers and domain experts to understand the model.
1. Entities: Is an object that has a thread of continuity. It has a unique identifier but it is not defined by its attributes. The object is mutable and the attributes can change but the identity will remain the same. For example, think of an order given in a restaurant. The order has a unique order number associated with it, however, the order changes its attribute from ordered, to cooking, to served.
2. Value Object: Is an object that defines a characteristic. It is immutable cannot be changed. These are attributes of entities that can be shared by multiple entities. The only way to change this attribute is to create a new instance and replace the old one.
3. Domain Event: Is an object that is used to define an event. Domain events are those which that have significant impact to the domain experts, therefore, not all technical events will be domain events.
4. Services: Is any stateless operation that does not affect or is related to an entity or a value object.
5. Aggregate: Is a group of entities and value objects defined in a boundary. The entities and value objects in an aggregate cannot be accessed by an external object except for one entity that is known as the
6. Aggregate Root. The aggregate root is the only entity which other objects can interact with and send instructions to the whole of the aggregate.
7. Repositories: Is an interface where the entities, value objects, and aggregates can be accessed. Different methods can be defined to create, delete, and modify these objects. The repository makes it easier for the user to access these objects without getting into the complexities of where and how they are stored.
8. Factories: Another abstraction that is used to make complex objects, such as an aggregate. This will enable the user to create these objects with an atomic function without worrying about the underlying working of the system.
Example Project
With this little project of myself, I want to show you how to use DDD in the real world.
The Core Domain
Inside of the core domain, there are the most important classes and Interfaces our application uses. It has a DocumentService class, which is the class that handles the most of our business logic. Then we have the entities Document and Metadata. These are used to store informations about documentations like the id or the title.
To save these entities from above, we have the DocumentRepository and MetadataRepository Interfaces.
The implementation of these two is handled in the infrastructure layer.
The Application Services
We have only two application services. The first one handles the upload of the documentation and the other one provides these documentation as a download. They can do this by using the Repositories and the Zip class from infrastructure.
The Infrastructure
The Zip class provides methods for zipping and unzipping the uploaded documentation. The repositories are implementations for the repository interfaces in the core domain. They use the filesystem to persist the data. These three classes are all passive and only get triggered from the application itself.
The restApis on the other hand are active infrastructure components. They can be triggered from outside by a user. The gradleRestApi for example provides a way to upload and delete documentations, while the userRestApi only has read access to these documentations.
The Tech Platform