http://domaindrivendesign.org gives the somewhat "official" definition of Domain-Driven design (DDD):
Over the last decade or two, a philosophy has developed as an undercurrent in the object community.
The premise of domain-driven design is two-fold:
- For most software projects, the primary focus should be on the domain and domain logic;
- Complex domain designs should be based on a model.
Domain-driven design is not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains.
Of course, this particular architecture is customizable according to the
needs of each project.
We simply propose following an architecture that serves as a baseline to be modified or adapted by architects according to their needs and requirements.
In respect to other kinds of Multi-Tier architectures, DDD introduces some restrictive patterns, for a cleaner design:
- Focus on the Domain - i.e. a particular kind of knowledge;
- Define Bounded contexts within this domain;
- Create an evolving Model of the domain, ready-to-be consummed by applications;
- Identify some kind of objects - called Value objects or Entity Objects / Aggregates;
- Use an Ubiquitous Language in resulting model and code;
- Isolate the domain from other kind of concern (e.g. persistence should not be called from the domain layer - i.e. the domain should not be polluted by technical considerations, but rely on the Factory and Repository patterns);
- Publish the domain as well-defined uncoupled Services;
- Integrate the domain services with existing applications or legacy code.
The following diagram is a map of the patterns presented and the
relationships between them.
It is inspired from the one included in the Eric Evans's reference book, "Domain-Driven Design", Addison-Wesley, 2004 (and updated to take in account some points appeared since).
You may recognize a lot of existing patterns you already met or implemented. What makes DDD unique is that those patterns have been organized around some clear concepts, thanks to decades of business software experiment.
Is DDD good for you?
Domain-Driven design is not to be used everywhere, and in every situation.
First of all, the following are pre-requisites of using DDD:
- Identified and well-bounded domain (e.g. your business target should be clearly identified);
- You must have access to domain experts to establish a creative collaboration, in an iterative (may be agile) way;
- Skilled team, able to write clean code - note also that since DDD is more about code expressiveness than technology, it may not appear so "trendy" to youngest developers;
- You want your internal team to accumulate knowledge of the domain - therefore, outsourcing may be constrained to applications, not the core domain.
Then check that DDD is worth it, i.e. if:
- It helps you solving the problem area you are trying to address;
- It meets your strategic goals: DDD is to be used where you will get your business money, and make you distinctive from your competitors;
- You need to bring clarity, and need to solve inner complexity, e.g. modeling a lot of rules (you won't use DDD to build simple applications - in this case, RAD may be enough);
- Your business is exploring: your goal is identified, but you do not know how to accomplish it;
- Don't have all of these concerns, but at least one or two.
Perhaps DDD sounds more appealing to you now. In this case, our
mORMot framework would provide all the bricks you need to implement
it, focusing on your domain and letting the libraries do all the needed
If you identified that DDD is not to be used now, you will always find with mORMot the tools you need, ready to switch to DDD when it would be necessary.
Legacy systems will benefit from DDD patterns. Finding so-called seams, along with isolating your core domain, can be extremely valuable when using DDD techniques to refactor and tighten the highest value parts of your code. It is not mandatory to re-write your whole existing software with DDD patterns everywhere: once you have identified where your business strategy's core is, you can introduce DDD progressively in this area. Then, following continuous feedback, you will refine your code, adding regression tests, and isolating your domain code from end-user code.
Let's continue with part 2, which will define Domain-Driven Design high-level model principles.