This post will be the beginning of the description of the DDD approach to designing systems, based on the assumptions of the book Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans. There will be a little theory but also some life examples.
It will be divided into specific sub-topics:
- The main principles of the DDD approach to system design
- Ubiquitous language
- Bounded context
- Entity
- Value object
- Aggregate and root aggregate
- Layers of architecture and persistence ignorance
I start with the introduction and so what is the Domain Driven Design.
The main principles of the DDD approach to system design
The concept of design in accordance with the principle of Domain-driven Design is based on designing the system in a logical and consistent way that will be understandable for each person. The language that is used within a given domain must be unequivocal to everyone. A domain expert, a team of programmers or people who do not deal with IT on a daily basis should communicate with each other intelligibly without unnecessary translations in one of the groups.
An important element is to determine the model, i.e. clearly defined purpose of the given system. Of course, the model can evolve over time. A well-designed system in accordance with the DDD assumptions will be ready for these changes. The wrong assumption on the part of programmers is that the model should be designed already at the stage of creating the database, which is very fatal. This is because the relational databases designed at the beginning of the project when everyone does not understand the functioning of the entire model, most of them are incorrectly designed. Through this assumption, ordering patterns and relationships is complicated, time-consuming and incomprehensible for each of the parties.
In the DDD concept there should be one domain object without distinguishing between different levels of abstraction, that is: technical, analytical and design. A well-designed system should have layers: presentation, logic and infrastructure. Thanks to the DDD method, the business logic layer is understandable for all people and the representation of the model is separated from the dependencies such as the framework or database used, which over the years are changing, and are difficult to understand for non-technical people.By using the DDD method, the system will be consistently maintained and it will be easier to transfer it between different platforms or frameworks.
In the next posts I will describe more technical aspects of this approach.
They will appear every two weeks.
