Domain Driven Design: Introduction
Domain Driven Design (from now on DDD) is an approach to software design that focuses mainly on a business problem and how to organize the logic that solves it, leaving aside details like programming languages, infrastructure technologies, etc… DDD is about mapping real-world system or processes into software artifacts.
Let's review four important concepts to better understand what DDD is based on.
What is domain?
Domain is most commonly referred as business logic and rules. In using DDD, you are meant to work closely with a domain expert who can explain how the real-world system works. In other words, talk to the people in the businesses where you are solving problems and understand them from their point of view first.
What is ubiquitous language?
Between yourself and the domain experts, you build a ubiquitous language (UL), which is a common set of terms and definitions used by the entire team, both technical and nontechnical. The idea is that you should be able to write down what the system does in a way that the domain expert can read it and verify that it is correct.
What is bounded context?
Bounded Contexts actually represent divisions in order to deal with large domain models. It groups related components and concepts and avoids ambiguity as some of these could have similar meanings without a clear context.
What is an aggregate?
An aggregate is a DDD pattern. It’s a cluster of domain objects treated as one single unit. An aggregate will have one of its component objects as aggregate root. Any references from outside the aggregate should only go to the aggregate root. Aggregates are fundamentally about defining consistency boundaries and enforcing invariants.
In future posts we will review DDD layers, elements, patterns, as well as best practices.
To be continued...