MICROSERVICES .NET CORE WITH EXAMPLE — Part 3
Introduction
Domain-Driven Design, or DDD, is a software development approach helping us to achieve high-quality software. It talks about problems as domains in the context of building applications. DDD also deeply values the domain model and connects it to the implementation).
DDD focuses on 4 main principles:
- Focus on the core domain: the area of the product that will give you a competitive advantage and generate real value for your business.
- Learn through collaboration: it’s very important to collaborate between the development teams and business experts to produce useful models to solve problems. As the result of this collaboration, the business has the opportunity to learn much more about its domain.
- Create Models through exploration and experimentation: Eric Evans, the author of “Domain-Driven Design: Tackling Complexity in Software”, suggests for every good design there must be at least 3 bad ones. By spending time prototyping and experimenting can go a long way in helping you shape a better design.
- Communication: a shared language to collaborate effectively between the business and development teams to solve problems. It helps to bind analysis and mental models produced (in knowledge‐crunching sessions between the teams) to a technical implementation.
DDD terminologies
To be easier to understand, let’s have an example: imagine that you want to build a big farm for your business, the visualization is below:
The farm has many different parts, such as main house, garden, shed, barn, stables…etc. Let’s jump inside this visualization to see what DDD terms there.
1. Domain: refers to the specific subject that the project is being developed for (example: hospital, hotel management… — we name it). We can call the domain as the world of the business.
So in this case, we can call the farm as the domain (easy to understand, right?)
2. Sub-domain
Because the domain concept is abstract and quite broad therefore we want to split it up into smaller parts called sub-domains to make to domain more concrete and tangible.
Sub-domains can be divided into 3 categories:
- Core domains: what makes an organization different and special from others, that’s why it should receive the highest priority (best engineers and biggest effort for it).
- Supporting sub-domains: necessary but not in core domain or generic sub-domains.
Supporting sub-domains help to perform ancillary, supporting functions related directly to what the business does.
- Generic sub-domains: less valuable for business than Core domain. It also is generic enough to allow buying it off the shelf (unlike supporting domain).
Come back to the sample, the farm has many different parts (garden, stables…) and they are the sub-domains of the farm domain.
3. Model: the solution to the problem
The model often simplifies the bigger picture, therefore it should be focused knowledge around a specific problem that is simplified and structured to a solution.
4. Domain model: a model for a domain
Domain model could be a code samples, a diagram or document of the problem, as long as it is accessible and understandable by everyone in project.
There are many sub-domains in the farm domain, and we need to create modes for each sub-domain. Basically these models will be detailed models and these detailed models are generally known as domain model.
5. Context: the settings in which a word or a statement appears that determines its meaning.
6. Bounded context
Each sub-domain should have explicit responsibilities so it has a boundary to limit their functionalities, the boundary will help sub-domain focus to do only one thing and process well. This boundary is considered as bounded context of the sub domain.
In another word, a sub-domain delimits the applicability of a domain and exists within the problem space. A bounded context delimits the applicability of the domain model and exists within the solution space.
There are many tutorials about problem spaces and solution space, you can reference this link for more detail.
So if the stables, garden… are sub-domains then the bounded context will be the boundary around them (red circles)
7. Context map
The bounded contexts have some relationships among each others, and if we make the diagram of how bounded contexts relate to each others, that is known as the context map.
8. Ubiquitous language: a set of terms around the domain model and used by all people involved in project to connect all activities of the team.
The ubiquitous language brings together the domain experts, the technical team, and the others involved in the project.
Come back to our example, before building the complete farm we need to make the blueprint for it. All the described texts in this blueprint, such as kitchen, living room, bed room…, are called ubiquitous language.
9. Entity and Value object
- Entity: an identified object which is defined by its attributes
- Value object: an immutable object which has attributes but no distinct identity.
For example, if you go the the library and looking for the book Harry Potter, and you find two same book. In your perspective, these books are value objects because they make no difference for you to pick one of them. However, they are 2 entities in librarian’s perspective. They need to be labeled to distinguish between each other.
10. Aggregate
In the book Domain Driven Design describes an abstraction, Eric Evans called “aggregate”:
An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes. Each aggregate has a root and a boundary.
Therefore,
Cluster the entities and value objects into aggregates and define boundaries around each. Choose one entity to be the root of each aggregate, and control all access to the objects inside the boundary through the root. Allow external objects to hold references to the root only.
Aggregates are sometimes confused with collection classes (list, dictionary, etc). The aggregates are domain concepts while collections are generic. An aggregate will often contain multiple collections, together with simple fields.
Pros and Cons
1. Pros
- Easy communication: DDD approach forces you to define the terminology (ubiquitous language). It works well when you know what jargon is used within the application domain
- Extend flexibility
- Better Code: you end up with more readable code and less duplication, and the result of it is good software architecture
2. Cons
- Require strong domain experts
- Miscommunication between technical and domain experts in complicated systems
- Require team to be dynamic and flexible because implemented modules and models can be changed frequently
- Only need if domain is complex
