Domain Driven Design
Introduction
Domain Driven Principle is a powerful principle aiming to solve problem for a project related to a complex domain, it advocates how engineers communicate with domain experts and how to embody the domain knowledge into the software.
DDD works very well with onion architecture that emphasis on making use business logic as it’s core and architect the software with different layers for SRP, testability, flexibility etc. making use of a inward dependency flow.
Approach complex domain
Building software especially to solve problems for a complex domain require domain knowledge, and the key towards building a compelling and extensible application to solve such problems, as a developers we have to keep communicating with the domain experts, build the communication bridge (ubiquitous language), inject them into the application, trial and errors, find out what the core problems (features) to solve and re-model the application if needed in the process.
- Keep asking questions and create rough diagram (build common language)
- Build basic demo (prove of concept)
- Figure out what problem needs to be solved and what is not necessary
- Improve diagram into modelling
- Remodel if needed
As a developer, we want to application to be extensible and not only focusing on making the current requirements work.
Tools to help to approach the complex domain
Ubiquitous language
Ubiquitous language can help breaking the wall between the domain experts and developers within the entire software lifecycle, which also can be used in the codebase as we know the software is surrounding the business logic as it’s core since it is built to solve problem (or make convinent) for the domain.
- Application modelled base on the domain (bounded context), easier to extend from the solid context.
- Even developers with such domain knowledge left the company, since the application built on top of domain languages, it helps / forces people to understand the domain.
High Level UML diagram
When dealing with the jargons throwing by the domain experts, drawing high level UML diagram helps to illustrate the entities, and relationships better, for example class diagram and object-interactions diagram (or sequence etc.).
The diagram can be distilled or refactored in the discussion which are very useful to visually let the domain experts and developers to better communicate.
Actively learning the domain knowledge
Domain knowledge can not be ‘injected’ by someone, it requires the engineers to proactively learn from books, online etc. And eventually help them to understand and easily to implement domain related use cases in the codebase.
It won’t be easy but it is something that you learn, you get better and eventually get good on learning new domain knowledge, it is a skill sets that can empower you the entire life.
Moreover, most of the cases the developers don’t get the chance to directly interact with the domain experts, but via a project manager or BA etc. Which they won’t be understand why you would know “that much” and might refuse to communicate with you.
Jargons in DDD
Domain / Problem Domain: The domain logic that the software is trying to resolve or achieve.
Domain Model: The solution to the problem domain.
Entity: Required to be identify by ID (Which are they) / reference equality, which it’s importance in the domain compare to value object.
Value Object: Does not have ID (What are they) but equality can be identified by reference and structural equality. They must be part of one or many entities, it is a group of data in a class / file that must be immutable (since they can be reference in many places).
Aggregate: A small group of entities and value objects (~2–3), each aggregate will have a root entity which act as the interact point of the aggregate and might have a version and handle the domain event.
To separate from a big aggregate, one way is to see if any entity in the root entity actually can live alone without the root entity or one to many relationship exists which can affect the performance, then it might be a good reason to separate it as another aggregate.
Boundary Context: Like a subdomain in a domain that have clearly different problem to be solved. The nicely separated boundary context allow engineers to easily understand what’s happening in that specific context and give the features from that context to grow without being messy and spaghetti.
A ubiquitous word in different boundary context can have different meaning, for example product means different thing to boundary context sales (focus on price etc.), warehouse (stock etc.) and purchasing (cost etc.).
TO BE CONTINUED.
