Illustrator: Finnur Alfred Finnsen
Having many people working on a software project, you sometimes wish that the domain experts and the development team are using the same domain language. The development team may not use the domain language used by the domain experts and vice versa. Developers may misunderstand important functional requirements. We also want to have a design system that can scale and guide us to create the right domain entities. This will ensure that our business and software are aligned, well documented and understood by everyone. That’s were domain drive design can help.
You want to improve your craft and increase success on your current project. You care deeply about crafting software that correctly models your business needs and also performs at scale anywhere using the best software architecture. This article will inspire you to use DDD in your project.
What is DDD?
Domain Driven Design is a set of tools that help you in designing and implementing software that delivers high value both strategically and tactically.
Some companies see software development as a cost-heavy center rather than a profit center. Developers are too busy with technology. They are trying to solve problems using technology rather than careful thought and design.
Why do we need DDD?
We are giving the database too much priority and most design discussions about the solution are pointed to the database and the data model rather than the business process and operations. There are wrong abstractions were developers attempt to address all current and imagined future of overlay generalizing solutions rather than addressing business needs. A good example of that is if we look at how roads used to be built. We model where we acknowledge modeling or not. Ancient roads started out as a cart path that was eventually molded into good trails. These trails took you to too many turns and forks that only a few uses. These paths were smoothened and then paved away for the comfort of having any number of passengers who actually use them. If we look at modern roads, we see that they are planned and designed according to careful studies of population, environment and predictable flow.
We need good design because it is effective. Effective design meets the business organization to the extent that it can distinguish itself from its competition by means of software. It forces the business to understand what it must be good at and is used to guide the creation of the correct software model.
How can I use DDD?
Start designing with strategic design. Highlight what is strategically important to your business and divide up the work by importance and how to best integrate as needed.
Second, use tactical design to paint the fine details of your software domain model by using something called aggregate entities and value objects. This makes use of the aggregate pattern and domain events. We will take a look at this soon.
Domain Driven Design split up software into Bounded contexts. These are the boundary which each component of the software model has specific things and does specific things. The components inside the bounded context are context specific. Think of it as your problem space. Each bounded context has its own software artifact.
When you finish creating unique bounded context. It will be called the solution space where you actually have implemented a solution.
Bounded context also a boundary that allows the team members to speak the same language. The language is spoken by the team members while implementing its software model. It is important that the language is correct, strict, exact, precise, and right.
One team should be assigned to work on one bounded context with separate source code repository. One team can have multiple bounded contexts but we should be careful to not to have multiple teams in a single bounded context.
What is inside a bounded context?
Aggregates are the things inside the bounded context. They are from the aggregate model. Each aggregate is composed of one or two entities where they may have a value object (a simple value that models immutable computation).
Entities models an individual thing. Each has a unique identity in what you can distinguish.
Domain Driven design helps you identify business needs by creating a correct bounded context but how can you share a language that identifies those needs? Meet ubiquitous language. After you as a developer and domain expert sit and find the core domains. Start by exploring your core domains as a set of concrete scenarios about what the domain model is supposed to do. It should not contain any concepts related to the technical implementation of your software solution. However, the Language is more centered on how the business itself thinks and operates. The goal is to achieve the very best Language for the project.
“In order to reduce death in patients
We have to follow a checklist of to-do´s
That will ensure patient safety.”
Now that you have the scenarios set. You have to transition to a software artifact that can be used to validate your domain model against the team specs. This technique is called Specification by example and it´s also called Behavior Driven Development. You simply start programming acceptance tests to test your model from the written scenarios. There are many frameworks that allow you to do BDD. My favorite is Spock, but you can also use Junit or Cucumber [https://cucumber.io/].
A bounded context can communicate with another bounded context. We call that context mapping in Domain Driven Design. There are many types of context mappings. There are also many types of ways to integrate between two different bounded contexts. The best way we recommend is messaging. Messaging is a robust form of integration. A domain event is a record of some business significant occurrence in a bounded context. These are usually recorded too so that we know what is happening. You can easily implement this in Apache Kafka.
The aim of this article is to get you motivated to read more about Domain Driven Design and to start using it in your project. It has helped me define boundaries and help my team separate big software artifacts called Big Pile of Mud into smaller software artifacts, called Microservices today that mirror the business better.