Domain Driven Design (DDD) is an approach to software development that emphasizes understanding the business domain and creating a flexible Domain Model that is closely aligned with it. The goal of DDD is to create software that is not just technically correct, but also satisfies the needs of the business.
Eric Evans, the author of the book « Domain-Driven Design: Tackling Complexity in the Heart of Software, » defines DDD as follows:
« Domain-Driven Design is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain. »
DDD is not just about the code, but also about the people who work on it. It involves collaboration between developers, domain experts, and stakeholders to create software that accurately reflects the needs of the business.
Key Concepts in DDD
Bounded Context
« A Bounded Context delimits the applicability of a particular model so that team members have a clear and shared understanding of what has to be consistent and what can develop independently. »
Eric Evans
One of the key concepts in DDD is the idea of Bounded Context.
The purpose of a bounded context is to provide a clear separation of concerns and to help avoid conflicts and confusion between different parts of a system. Within a bounded context, the language, concepts, and models used are specific to that context and may be different from those used in other bounded contexts.
In DDD, a system may have multiple bounded contexts, each focused on a specific area of the business domain. These bounded contexts may interact with each other, but they should be designed and implemented independently to ensure that each context is optimized for its specific purpose.
Ubiquitous Language
« The language is both written (in diagrams, documents, and code) and spoken (in conversations among team members, with domain experts, and with users). »
Eric Evans
Another important concept in DDD is the idea of Ubiquitous Language. A Ubiquitous Language is a common language that is used consistently throughout the development process, from the domain experts to the developers to the code itself. A Ubiquitous Language helps ensure that everyone involved in the project has a shared understanding of the business domain and its terminology.
Domain Model
« A model is not just a data structure; it is not just a set of methods or operations, either. A model encapsulates a way of understanding some phenomenon of the real world. »
Eric Evans
The Domain Model is the central concept in DDD. The Domain Model is a representation of the business domain in code, and consists of entities, value objects, and relationships between them. The Domain Model should be simple, flexible, and maintainable, and should evolve as the business needs change over time.
Layers
« In a layered architecture, the layers themselves are independent and replaceable, with each layer dependent only on the layer below it and serving as the foundation for the layer above. »
Eric Evans
DDD also emphasizes the importance of separating concerns and promoting modularity through layers. The layers typically include the User Interface, Application, Domain, and Infrastructure layers. Each layer has a specific responsibility, and interactions between layers are controlled by well-defined interfaces.
Conclusion
Domain Driven Development is an approach to software development that emphasizes understanding the business domain and creating a flexible Domain Model that is closely aligned with it. Key concepts in DDD include Bounded Context, Ubiquitous Language, Domain Model, and Layers.
I hope this article has helped you gain a better understanding of Domain Driven Development! For further reading, I recommend checking out Eric Evans’ book « Domain-Driven Design: Tackling Complexity in the Heart of Software« and the Microsoft documentation on Domain-Driven Design with .NET Core.
Support me on Ko-fi
Laisser un commentaire