- Focusing on the business domain can give you a lot of value – even applying one small thing from DDD. You don’t need to understand everything at once, to begin with.
- Context is the king! Learn Wardley maps to make your discussions more efficient and help you make decisions.
- Autonomous needs an alignment. Otherwise, it is just chaos.
I was at the conference called uConf, which was about domain-driven design, microservices and software architecture. It was a 3-day conference, so there’s a lot of content which probably I am not able to summarise. So my summarise will not be talk-by-talk, but instead, I will try to present the DDD topic as a holistic view from all talks.
1 What is the domain?
The domain represents part of the process in the system. The whole system can have multiple domains like order-taking, shipping, billing and so on. Usually, the DDD approach is used to express complex problem space. The whole domain should be described with the consistent language used by everyone. Language is specific to the domain. Such a language is called a ubiquitous language.
We can distinguish different subdomain types:
- generic domain – not valuable from the business perspective. It is not unique to the provided business. It can be easily bought from 3rd parties.
- supportive domain – important, required from the core perspective, but doesn’t offer a competitive advantage.
- core domain – critical to the business, because this is what business is trying to sell and solve. This is what a specific company should be good at.
So the core domain is the heart of the thing which you are trying to solve.
2 How to model your domain?
As said above, you tried to discover your domain analysing the process, not entities. The relationships are crucial to an understanding domain, so staring modelling with entities can lead you to the rabbit hole if you start with them prematurely. The most common way to discover the domain and describe the processes is event storming. The event is something that happened in the domain. They are records of something happened, so usually we write them in the past tense. Events become a building block of scenarios, use-cases, business process and workflow.
There exist another approach called temporal modelling, where you try not to model entities, but compose them from events itself. In that case, your entities are a projection of events. You can understand such an entity as an interpretation of events which creates it.
Another important thing while modelling your domain is to discover bounded contexts. DDD deal with large models by splitting it do different bounded contexts. Bounded contexts delimit the applicability of domain models. You can understand the bounded context as an analogy to the animal’s cell. One context/cell doesn’t know about another. It’s called context because each context represents some specialised knowledge in the solution. Within the context, we share the common language. It’s bounded because we want to make it evolving independently from other subsystems.
The helpful hint to detect the “Bounded context.” is to try to find boundaries of the domain. You should make the context boundary explicit because it makes it easier to manage. Bounded context is not equal to a unit of deployment. You can have multiple microservice which will still produce one bounded context.
3 How to find the most important thing?
To identify what is the essential thing in your business Wardley map approach can help you make that decision. First of all, due to Wardley, it is a map, because the place where you put a thing has a meaning. This map is 2D coordinate:
- The vertical axis shows you how your components are visible to a user (direct need of user).
- The horizontal one shows the evolution of the component (phase/stage: genesis, custom-built, product + rental, commodity).
So after drawing coordinates you start from the top because you would like to define user needs. You bring components/activities/dependencies, which are the most visible to the user and valuable for the user. Then you draw subcomponents which are required to provide the former functionality, with deciding where to put in the evolution phase.
Such a map gives you an overview of your business, and you can optimise things, by finding a path in the graph to change. You can delegate some components that don’t need to be done by yourself. Wardley claims that there are two `whys` in the business:
- why of purpose,
- why of movement.
And you can optimise in both ways.
The map doesn’t give you a solution. It just reflects your assumptions about the business. The most valuable thing is to show it to someone else, where the discussion begins that some element maybe is wrongly localised.
Here is visualized introduction to Wardley maps: