Domain driven design: Design tool for every role in team
Usually thinking in the industry is that software design tools are only meant for developers. But this is not the case with DDD, infact its one tool which needs to be understood by business and engineering team both. If you still don’t believe me, read on and you will know how understanding this will help software development?
Why Domain Driven design
When I was in management role I will always find myself lost in tech discussion and will take lots of water break in meetings. After the meeting I will catch one developer in the team and will try to understand the problem in delivering and solution which we have agreed upon. Reason, I was not able to understand their language. Then I started observing all the discussions whether it’s in management rooms or in were supposed to be about requirements. Lots of people were lost where technical people were involved and finally discussions end answering 2 simple questions at the end.
Can we do it ?How much time it will take?
Reason, Most of the people don’t understand those tech reasons and discussions which starts or continues with low level class diagrams and values.
Thats the problem which DDD aims to solve for us to some extent. Enabling active participation from lots of business role in discussions as it advocates people using same language while talking about product, solution or problem.
As the name itself suggest, design is driven from domain, which makes it easy for everyone to understand, participate, appreciate and suggest.
How DDD achieves it
DDD is an approach to developing software that focuses on these three primary aspects:
- DDD brings domain experts and tech teams together in order to develop software that reflects the mental picture of business experts.
- DDD best practices generally address a dozen or more higher-level architectural and lower-level software design concerns, with a focus on recognizing true business rules and data invariants, and protecting the rules from error situations.
How to do DDD
To explain different tools for DDD, lets take example of scrum project management tool and understand every tool.
1. Ubiquitous Language: The Ubiquitous Language is a shared language developed by the team — a team composed of both domain experts and software developers. No matter what is your role on the team, since you are on the team you use the Ubiquitous Language of the project.
Naturally, the domain experts have a heavy influence on the Language because they know that part of the business best . However, the Language is more centred on how the business itself thinks and operates.
If you have scenario like this:
The product owner commits a backlog item to a sprint.
Code can be like this:
var backlogItem = BacklogItemScheduledForRelease();var productOwner = ProductOwnerOf(backlogItem);var sprint = SprintForCommitment();backlogItem.CommitTo(sprint, productOwner);
Domain: Domain can refer to both the entire domain of the business, as well as just one core or supporting area of it, which business is looking to solve at this time. In the use case we have considered, Scrum project management tool is our domain.
Subdomain: It’s a small part of domain which is represents to one concern of business. In Forums, Discussions could be other subdomains.
Bounded Context: Bounded context is a solution which solves one particular problem for business. It helps in identify what all closely related subdomains are required to solve the problem. It will have its own ubiquitous language. In our example, Considering different subdomains, Product will become one bounded context, while user accounts, calendars will be different bounded context.
Entity: An object with an id is an entity. You can change every other value of that object but as id is the only one which distinguishes it. For example, backlog items, Release, sprint.
Value object: This is an object without id. If any of its variants changes, the object is considered to be another object. For example, tags defined to bucket backlog items. As you change the value it becomes another tag. It’s a good practice to make the value objects immutable, so that when once created it can never be changed.
Context Map: Context map represents the relation between Bounded contexts. Like, relation between backlog product bounded context will share relationship with account bounded context because of shared user.
Domain event: A domain event is a full-fledged part of the domain model, a representation of something that has happened in the domain. Assigning backlog item to release.
Aggregates: The aggregate is a model that represents all the relevant information we need to change something. Every time we want to make changes, we need to identify the aggregate that tell us the relevant components and the rules they must respect. For example, Sprint aggregate will have sprint Id, committed backlog item and all the rules required for sprint. Entities with business rules will become aggregates. Aggregates helps in designing microservice. One aggreagate can be one microserivce.
Hope this helps to understand basic building blocks provided by domain driven design in short. I find Implementing domain driven design by Vaughn Vermon very useful for undestanding DDD.
If I have to start with one tool I will always go for ubiquitous language in discussion and in implementation as well.
