Basic concepts of Domain Driven Design
I would like to write what I understand from DDD. Let’s start with basic definations.
- Business logic can be expressed in If- else and loops. That’s it
- Business rules are the hearth of software development
- Domain could be divided into 3 sub-categories
→ Core Domain
→ Generics Domain
→ Supporting Domain
Core subdomains are the most complicated one. The main business runs in core domains. The organization’s core competitive power comes from this domain.
Generic subdomains are less complicated business areas. Examples for generic domains are accounting service or online internet e-commerce platforms. Generic subdomain doesn’t give organizations a competitive advantage.
Supporting subdomains are less complicated ones. Like CRUD operations. Copying generic or supporting subdomain is not important as copying the core subdomain from other organizations Creating software comes as a by-product of a learning process.
Ubiquitous language is the most challenging part of DDD. From my understanding point of view. Ubiquitous language is very similar to value stream mapping in the Lean world.
The Bounded Context term also is a very confusing part of DDD. In order to define a bounded context term, I would like to refer to the Kanban Method. In the Kanban Method we have to look at the organization of service lenses. You can think of service as a system.
Several systems (subdomains) can be put in a bounded context. There are basicly two kinds of relations
- One bounded context : One subdomain
- One bounded context : Several subdomains
Let’s combine all terms together : Ubiquitous language, bounded context and subdomains
Without understanding the value stream (ubiquitous language) it is not possible to create value for customers. If you show all bounded-context and their relations on the value stream that you will get a context-map.
How to integrate a bounded context ? There are several ways to do that
- Shared context
- Customer-supplier
- Conformist
- Anti corruption layer
- Open host service
Shared context can be represent like below
Todo -Doing -Done is an example generic value stream.
Ready column is the shared part of these two bounded contexts. Let’s talk about customer-supplier and conformist concepts :
Two bounded contexts integrated via customer-supplier + conformist pattern. Downstream bounded-context accepted without filtering from upstream bounded-context.
What happens if downstream bounded-context needs a filtering mechanism? That’s where anti-corruption patterns comes in.
Anti-corruption layer works on downstream bounded-context. If you would like to move the filtering mechanism from downstream to upstream you can use Open Host Service approach.
In that scenario upstream bounded context transforms the model into a more generic language for the downstream bounded-context. In this case downstream bounded no more need an anti corruption layer.
Tactical side of the Domain Driven Design
There are 4 types of DDD tactical approach
- Aggregates
- Value objects
- Domain events
- Domain services
You can pick an Entity object as aggregate. There is a hierarchical model behind the aggregates. For example you have a customer. Customers have an address, customers have an account and so on.
- Customer (aggregate)
→ Address (value object)
→ Status (value object)
→ Account (entity)
→ → Private accounts (entity)
→ → Public accounts (entity)
As you can sense from the above hierarchical model, the coordination level object is Customer. All state of the customer aggregate is controlled by Customer object’s public interfaces (methods).
Domain events represent the states of the event. Domain events tell a story or put a process. For example, a customer’s status can change with a domain event from state to state like below :
- If customer come to the system first time : NEW_LEAD
- If customer go from the system without a payment : CLOSED
- If customer go to silent mode then we need to follow up : FELLOW_UP
- If customer buy from us then we are successful : CONVERTED
- If customer is in the system but waiting : WAITING
Domain services are like a self cowboy in the system. They don’t belong to an aggregate. Domain services should be stateless. They are coordination level objects.
Domain services are like a self cowboy in the system. They don’t belong to an aggregate. Domain services should be stateless. They are coordination level objects.
Stay with DDD.
