Simplifying Complexity with Doman-Driven Design
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. Business rules are intended to assert business structure or to control or influence the behavior of the business. What DDD help us with is identifying such rules and sharing them with stakeholders involved in the project.
Domain-Driven Design intends to bring all the concepts from the Core domain into the code. We approach a complete and comprehensible model by using the model-based Language and only being satisfied once it flows. An explicit model defines the technical details of the model. Several Explicit models represent a Bounded Context. Simple concepts in a system 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 one on the same.
Ubiquitous Language is a common language between businesses and software developers. A model can be anything the people involved with the domain agree on. The Ubiquitous Language is another way to represent a model.
The Ubiquitous Language is a shared language developed by domain experts and software developers. Domain-Driven Design models the ubiquitous Language per Bounded Context. Ubiquitous Language reflects the structure of the model. The systems that the model suggests should show up in the Software.
To deliver the proper Software, we focus on the complexity of the whole business rather than on the technical part of it. The tools are only relevant if the efforts to solve a problem point in the right direction. Complexity in the domain is no longer according to the problem, so we don’t have to speed up coding. We don’t have to use frameworks to type faster, scaffold code, etc. That’s not the problem anymore. Using tools to deliver Software more quickly doesn’t mean that the final solution will end up working, be cost-effective, or even scale.
