Simplifying Complexity with Domain-Driven Design
DDD is all about sharing and publicizing the mental model between interested parties. With Domain-Driven Design, the goal is to reduce complexity by separating the essential things from the important ones.
Business rules are rules or procedures that make or save the business money. Business rules describe the operations, definitions, and constraints that apply to an organization. Business rules define business constraints.
What DDD help us with is identifying such rules and share with both parties. It accomplishes this by emphasizing the promotion of the Ubiquitous Language as part of its main principles. We let the design emerge. We do emerging requirements. DDD intends to bring all the concepts from the Core domain into the code. An explicit model defines the technical details of the model. The explicit model defines actors, aggregates, and entities representing Domain Model. A domain is what an organization does and the world it does it in. A domain is any formalization of a process. We share that the domain doesn’t change anything about an environment. We could use diagrams as we could use plain text.
DDD brings domain experts and developers together. The goal is to develop software that reflects the mental model of the business experts. We, developers, are technical thinkers. Technical solutions come for us. It’s not that thinking is terrible. There are times when thinking in technical terms, less is better.
The business core Domain is a part of the business Domain that is of primary importance to the organization’s success. The business core Domain is what makes the business unique. Each business sub-domain maps to a department.
Defining Bounded Contexts communicates state change using Domain events. The stream of events represents the system’s state at any given time, thus the Core domain of the system. We approach a complete and comprehensible model by using the model-based Language and only being satisfied once it flows. Simple concepts in a design make the model understandable. Combining and re-arranging simple concepts lead to bigger and more complex ones.
Instead of building UML diagrams, the idea is to use the code as the model. Domain-driven design is the fact that the model is the code, so you don’t draw UML diagrams as a model and then write code afterward; they are identical.
[¹]: Domain-Driven Design: Tackling Complexity in the Heart of Software
