It’s been a while since the introduction of microservices to address issues in contemporary application development. The fundamental ideas behind the microservices architecture are based on the concepts of domain-driven design.

Microservices and domain-driven design (DDD) are complementary approaches to software architecture in which the business domain is modelled in software and changed over time apart from the plumbing that makes the system run.

Let’s talk about what domain-driven design is and what rules it gives for making software.

To better grasp these ideas, how about using the real-world example of a Masala Dosa shop.

The basics

Our exploration of DDD will start with its more strategic and less technical aspects. It plays a crucial role in shaping your project, influencing the structure of the implementation and the coding style employed. It also has an impact on intra-team communication, ensuring that there is little room for misunderstanding. Because of this, we can move on to the next set of fundamental DDD ideas:

Domain

Simply put, it is a topic that our application is built around. Every part of the application was picked, coded, and put in place with the needs of the domain in mind.

The Dosa is the centre of our shop, and everything else needs to revolve around it. The chefs, the food, the menu, the signs advertising the restaurant, etc.

Subdomain

The domain model is broken up into subdomains, and each one is about a different part of the domain or problem that the digital product is trying to solve.

In our Dosa shop, the sub-domains are the different areas where Dosa is made and served, such as the kitchen, where Dosa is made, the serving area, where it is served, and the dining area, where it is served to customers to eat.

Model

The domain’s building blocks. When all these parts work together, they help solve a problem. In our case, our models are the people in their various roles, the ingredients, the dosa itself, the furniture, the machines, etc.

Ubiquitous Language

Every group of experts has their own jargon and language that shows what they know. In digital product development, many different types of experts work together. These include frontend and backend developers, as well as quality assurance specialists, business analysts, subject matter experts, and so on.

In our case, it’s the language the customer uses to order dosa, the language the waiter uses to talk to the chefs, and the language they use to talk to the cashier.

Bounded Context

The problem is described in detail and in a useful way by the domain model and its subdomains. The idea behind DDD is that the solution, including the way your digital product is coded, should look like the problem. The more complicated a domain is, though, the more likely it is that you will need to use subdomains.

Every worker in the shop will oversee different things. There’s not much chance that the chef and the cashier will switch jobs and need to know a lot about each other’s jobs.

So, now that we know how to talk about it, let’s look at the rules.

Model the software with the business domain in mind.

All decisions regarding architecture should be made with the business domain in mind. It is important to map the business models to the software components to facilitate communication between the two. The meaning of a term does not change depending on who uses it, be it a programmer or a corporate executive. The finished product of the software reflects the way the company functions.

If the owner of our shop refers to Masala Dosa, Plain Dosa, and Kali Dosa, it is advised that the cashier likewise refers to Dosa in accordance with this terminology rather than describing Dosa in a different manner. Both sides can better comprehend what is being said because of this.

The evolution of software occurs within a bounded context.

A subsystem is required to grow and think within the confines of a boundary that are described by a bounded context. It should not be concerned with the ways in which other bounded contexts evolve, nor should it attempt to address their problems on their behalf.

There is no requirement that the chefs’ approval be obtained before introducing new dosa delivery methods. In a similar vein, the individual making the delivery does not specify the required items that must be used in the kitchen. They are self-sufficient in solving difficulties and making changes to their work, which they do on their own initiative.

The operation of one subdomain does not interfere with the operation of another.

Construct domains by giving the advice of domain experts the most weight.

There is no justification for the development team to be oblivious to the requirements of the company. Before considering the technical domain, they should concentrate on gaining an understanding of the requirements from the point of view of the company.

Experts in the relevant domain are tasked with the role of refining the requirements. They are a point of contact to resolve any issues and record the requirements that are associated with a certain domain. Experts in each domain need not necessarily have a background in technology. They can be anyone who has studied the subject in depth and has experience working in the corresponding domain.

When our Dosa shop wants an advertising board, the owner goes to marketing specialists and designers. He does not make the decision regarding the design of the banner on his own. Neither does he defer to the judgement of the person who makes the banners.

The benefits of DDD

Let’s look at the benefits of implementing domain-driven design.

The use of domain-driven design is the best way to achieve coherence and consistency in the design process. To use a sledgehammer to shatter a nut is like using a case of using a case of using a sledgehammer to crack a nut. However, while it has the potential to be incredibly efficient, it may be too much for more straightforward digital products. DDD is best suited for complicated problems or products that are anticipated to work within and take account of a complex and varied business context, for example, several data sources, various relationships between data, and multiple outputs.

In a similar vein, one of the goals of DDD is to bring the technical and business components of the design process together. There is a good argument to be made that the use of a domain-driven strategy becomes more compelling as the significance of the business objective that your digital product helps to promote increases.

In conclusion, when you have a large and diverse design team as well as a group of stakeholders, having a common language because of being domain-driven helps ensure that clear communication and discussion can take place in an environment where misunderstandings could prove to be disastrous for your digital product.

Final word

It won’t come as a surprise to you to learn that there is a great deal more ground to cover. I haven’t even brought up aggregates, event storming, entity and value objects, event sourcing, CQRS, or any of the other numerous issues that may be discussed. My intention was to provide you with the essential information and to arouse your interest.

If you conclude that DDD is the best approach for your project, Vaughn Vernon’s excellent book provides a wealth of information on a variety of patterns, both strategic and tactical (link in references). Before you start wondering why I also haven’t mentioned Eric Evans’ renowned “blue book” here, let me just say that the sole reason is that I still haven’t gotten the chance to read it at the time that I’m writing this. You may relax knowing that it’s already on the list.

I have high hopes that reading this post will encourage you to continue your education and that it will also encourage more projects, both new and old, to implement DDD.

Thank you very much for reading. I really hope you found this post to be informative and helpful in gaining an understanding of domain-driven design. Now, it’s time to enjoy the deliciously cooked Dosa 😊