Leverage Domain Driven Design to boost your business

This article is a Domain Driven Design guide dedicated to non-technical, usually business people. It explains what Domain Driven Design is, what benefits it brings to your organization, when to use and when not this methodology, and of course, what business value this technique provides. I promise not to overuse complicated, technical terms. Instead, I focus on explaining the ideas and values for specific aspects of Domain Driven Design.

If you continue reading, you are probably a C-level or senior manager in an "IT-boosted" organization of any size (from startup to big tech). One day, some IT department representatives came to your office and said they wanted to use Domain Driven Design. They probably briefly explained what it means. You said, "ok, let's give it a try", as you thought it was yet another toy IT nerds want to play with. Then, after a few days, they invited you to a 4-hour meeting called a workshop. Apparently, there were also other business representatives from various departments of the company you manage. The IT guys asked you to stick some notes on the wall. You were really confused, but you started playing this game. After a couple of similar workshops, they came to you with a plan to reorganize the IT department. They discussed some maps, contexts, aggregates, and other complex technical terms you needed help understanding. You felt overwhelmed and confused.

Is it your fault? No! Is it the fault of the IT guys? Partially. They had good intentions. However, they could have made a bigger mistake. They missed the point of explaining what DDD is and how your company will benefit from this technique. They treated it as a plain IT approach that they don't need to explain to the business, like, for example, leveraging a new database or SCRUM ceremony. However, this is not the case if it comes to DDD. This is something bigger - something that requires the humble involvement of both the business and technology sides. Sometimes, it goes wider as other departments or even users are involved, too.

However, nothing is lost. If you've reached this paragraph, you are on an excellent way to understand it. So, let's start from the basics.

What is Domain Driven Design?

Domain Driven Design is a collection of patterns and good practices that support software development. It focuses on the complete understanding of the domain for which the software is developed. It helps to tackle the complexity of business processes which helps to deliver implementation that better fits the business needs and solves real business problems.

Now you may ask:
"So, you mean without DDD, the developers don't understand what they do?".

Of course, the answer is "No". However, some businesses' complexity is really high, and it's not easy to say, "I fully understand this business". One may not know that their understanding needs to be completed or corrected. Thus, DDD provides many tools that help continuously explore the business domain for better understanding. The community around this methodology still invents new practices that help teams craft software that better addresses the business' success.

Before I explain the concepts, tools, and patterns defined by DDD, let me quickly explain the term already used before - domain.

Domain

There is a lot of ambiguity around the domain term. However, for the purpose of this article, let's assume that the domain is a sphere of the interests of your business. In other words, this is what your company does to make money. Later, you'll see that usually, there are multiple domains, also called subdomains.

Understanding the business

The critical complexity of most software projects is in understanding the domain itself.
– Eric Evans, author of the first published book about DDD

One of the key concepts of DDD is knowledge crunching. It's extremely important that IT people understand your business, know how it makes money, and which processes are the most important for the company and which are not. This increases the chances that what is designed and crafted by architects and developers is what you and your users want. You probably pay quite a big salary to the IT department as they create the software that earns money for your company. Do you want them not to understand your business? I think your answer is "no".

However, you probably had a lot of discussions with them. And all the time, it wasn't easy to communicate. They use a lot of technical terms you don't really understand and care about. They talk about databases, APIs, and synchronous and asynchronous communication while you focus on the business processes, rules, and values. For this problem, the DDD community developed or adopted a couple of techniques that help to break down the communication barrier between business and IT. Those techniques are Event Storming, User Story Mappings, and Domain Storytelling, among others.

If you participated in an Event Storming session, you probably remember that it was a series of discussions and sticking notes on a wall. The main purpose of this workshop is to bring together the domain experts (anyone who offers knowledge about the domain, like product owners, users, specific department employees, etc.) and software developers in one room to learn from each other.

Event Storming, SoftwareMill, 2023.

Those techniques provide a couple of benefits to your company. First, as I already explained, they enhance IT professionals' understanding of the domain. Thanks to the structured format of those workshops, it's easy for participants to understand each other. Both business and IT people use the same terms and notation during the meeting. The form of those workshops supports breaking down the barrier between you and IT. Yet, it causes clashing of different perspectives. Because this workshop involves domain experts from various departments, any misunderstanding or misconception is quickly surfaced. Then it becomes straightforward to discuss and clarify it to be clear and coherent for all the stakeholders and developers. Moreover, based on the results of such workshops, you and IT create the artifacts, which help to craft better software solutions. We will discuss them in the following sections.

Divide and conquer

One widely used technique to manage complexity, not only in IT, is dividing the problem and solution into finer pieces. Think about the company. If it's a small startup with a few people on board, managing it by one person is relatively easy. However, the one-person management needs to scale better while it's growing. Then, the company becomes divided into departments, with a manager responsible for each. When it grows even more, probably the departments are split into smaller pieces with a network of managers responsible for them.

A similar solution is used in software craftsmanship. Building the software for complex business and its process requires dividing the problem into smaller parts. Thus, one of the artifacts of business exploration workshops is a vision of such parts. It allows the developers to use heuristics to split the domain into finer parts called subdomains to conquer it finally.

Event Storming board with system domain divided into finer parts.

What benefits does it bring to your business? Similar to the ones provided by dividing the company into departments. First, it helps to manage the complexity. Designing and building one solution for a big company is usually troublesome. However, if we divide it into smaller modules, it's relatively easy to manage. It also reduces the cognitive load required to work with a solution. If one needs to analyze and understand a single, non-modularized system, it's tough, even impossible. Usually, a developer doesn't need to understand the whole system to implement a new feature or fix a bug. Modularizing the system increases the speed of introducing changes and makes it less error-prone. Moreover, it gives the team autonomy and mastery, making them more efficient and motivated. I hope you already understand it results in gains for your business.

Prioritization

You probably defined the priorities in your company's strategy to know what you should focus on in the upcoming time to make the business successful. Thanks to the priorities, you know where to allocate your resources and what initiatives should be particularly invested to maximize profits.
This concept is also used in Domain Driven Design. Having the vision of the system divided into smaller parts, the next step is to categorize them. For that, the developers, together with you and domain experts, should discuss and establish the category for every subdomain of your business:

• Core - this is the most important part of your business. Those parts build your competitive advantage and earn money. This is why your customers love you. Thus, you and IT should apply the most effort to those modules. The core subdomain should be particularly discussed, and most of the workshop should be done around the functionality of this piece. The best developers and architects should be allocated to work on those modules. The complex business may contain multiple core domains.
• Supportive - this subdomain is optional for your company. However, it's vital for operating the core domain. It is less relevant but still crucial for the business to run. You and IT should only invest a little time and resources in this subdomain. Usually, it's a good place for junior developers to improve their skills.
• Generic - covers the functionality that is not critical and doesn't require much effort. Usually may be satisfied by off-the-shelf solutions or outsourced.

The system domain divided into subdomains.

To give you an example, let's imagine a fin-tech startup that grants online loans on various e-commerce platforms. The shop websites are your customers. However, the end users are shop users who buy the goods on the platform and want to use deferred payment or spread the payment into installments. Your business's competitive advantage is that the loan is granted very fast (most of the time, it's a one-click payment), affordable due to a low-interest rate, and highly available. Your business earns money from the interest and monthly fees, which are paid by e-commerce platforms that want to offer you loans on their website.

The part of the solution responsible for granting the loans, which consists of various processes from risk assessment to giving the loan itself, is your core domain. This is what pays your and your employees' salaries. You want this part to be highly invested, with the best experts on board and well-defined requirements and success criteria.

When your business grows, new customers use your services, and you grant more and more loans, you are required to introduce a KYC (Know Your Customer) process. It requires the users to provide detailed personal and financial operations as required in specific countries. However, this is not the process that is a vital part of your business model. It's necessary, and you have to implement it as the law requires it, and you don't want to pay penalty fees, but it's not what makes your business excellent. You just want to spend as much attention as necessary to do it, and no more. This is one of your subdomains.

Because you also charge e-commerce businesses for your services, you need to have an invoicing system. However, there is nothing specific in the invoicing process in your business. It works the same way for millions of different companies. Thus, using off-the-shelf solutions generally available in the market is good enough, as this is a generic subdomain.

I hope you already see the power of this concept. Knowing which part is essential for your business helps you to understand what to focus on. You can plan staffing and investments more efficiently. On the other hand, this may notice where the money leaks, as you put too much effort into unimportant parts. All in all, this helps to maximize the profit.

Common language

Have you ever had a situation where you talked with an IT representative and needed clarification about what you were talking about? You use business jargon, while a developer or architect uses a lot of technical terms like database, communication, events, etc. It usually takes a long time to be on the same page. Sometimes, it's even impossible to get along. You always feel frustrated after such situations, as it requires a lot of translations between business and technical terms.

I will tell you the truth. Developers hate it too. It's even more frustrating when one works with code that uses vague or outdated business terms, which is quite often the case. Then it requires even more translations. It's a nightmare.

This is why the developers in the DDD community invented the so-called ubiquitous language. The idea of this concept is to build a common language that is used by every person involved in the project. Starting from the business, through domain experts and project managers, to developers and testers. Even in the code, tests, and documentation, the same terms are used in the business jargon. There are no more translations between business and IT. All the people speak exactly the same language. Have you already calculated the time savings? Think about how it reduces frustration and supports collaboration between your employees.

Cross-teams collaboration

Do you remember the DevOps revolution? The idea was to bring the development and operation teams together to cooperate on a daily basis. That wasn't the case before. The developers used to work in complete isolation from operation teams and vice versa.

Domain Driven Design goes even further and brings IT (analysts, developers, architects, UX designers, and others) together with business stakeholders and domain experts to cooperate daily. So there are no more us and them. Now you are one team with a common goal. It's all to design and build the software, which is as much as possible valuable and consistent.

I believe, after reading the previous paragraphs, you already feel it. You work together with IT guys. You exchange your ideas and point of view during the workshops. You both create and care about the ubiquitous language. Together, you prioritized what is important for the business and what to focus on. Sounds like a dream? It's only DDD.

Team organization and relationships

Those are only a few initial concepts that stand for DDD. Many more patterns help you build an effective IT organization. For example, you know which part you should focus on by having the domain sliced into subdomains with priorities. This allows better team allocation and skill utilization. However, there are always dependencies between the subdomains. Thus, the teams must collaborate to a greater or lesser extent.

Domain Driven Design defines a set of patterns for team integrations. They determine how the models maintained by the team integrate, which is a more technical aspect. However, this brings valuable insights for managers too. Namely, by having the team relationships defined, you may build a map of them. This allows them to discover how they work and communicate. It also shows how the change influences them and which teams have to be involved in the development.

However, from your point of view, the most important benefit is that such a map quickly shows the bottlenecks, which are the suboptimal relations between the teams. This allows you to quickly identify them and redefine what, of course, translates to cost optimization due to better resource utilization.

Context map with a nonoptimal relationship marked (D - downstream, U - upstream)

In this example of a context map, some technical details are skipped for clarity. However, the point is that it shows a nonoptimal relationship between Customer Management context and Loan Issuing, which is the core of the business. The Loaners team responsible for loan issuing is a downstream side (D) which depends on the customer model provided by the Players team, which is the upstream side of the relation (U). This may cause, for example, some delays while introducing the changes in the loan issuing process, which is a vital part of the business, so it should be very flexible.

Technical patterns

In this article, I discussed some of the so-called strategic patterns, which help understand and map out the business domains, create and maintain the ubiquitous language, and plan team relations. I intentionally skipped another set of patterns, which are technical patterns architects and developers use while crafting the code. Those are called tactical patterns. I just want you to know that they exist and are probably extensively used by your development teams if you use Domain Driven Design.

What benefits do they bring? A couple of ones, however, from the business perspective, those patterns adhere to the profit and cost optimizations by making code that is easy to understand, reflects the ubiquitous language, and is modularized according to the subdomains and priorities you established. Finally, it's easy to maintain and change. In summary, it takes less time for developers to play with it while implementing new features or fixing critical bugs. Of course, it translates to faster time to market, user happiness, and finally to money.

When (not) to use DDD?

I hope you already understand the value DDD brings to your business. However, you probably also see the costs associated with all the activities mentioned in this article - workshops, meetings, daily collaboration… It all consumes time. And time is money. Thus, this methodology should be used consciously.

It perfectly fits large, complex businesses. But what is complex? There is no easy answer and a fixed border here. If the software's main purpose in your business is to collect and manage the data, and there are no business processes with a bunch of rules behind them, it doesn't make sense to incorporate DDD in such a case. It won't really help, but you will spend a lot of time using it. However, if your business involves a couple of complicated, not linear business processes, it's usually a good idea to use DDD.

Let me give you an example. Think about the system, which collects the users' emails, basic data, like name, surname and birth date, and agreements. Then it's used to send the email to subscribed users. It's quite an easy domain. It doesn't require complex patterns to understand and develop it. Now think about the cinema ticket-selling system. There are plenty of processes involved. First, the user may book seats in the cinema hall. But it doesn't necessarily mean they will come to the cinema and pay for the ticket. Thus, as you want to optimize the hall utilization, probably about 30 minutes before the movie begins, all not consumed reservations are canceled. But you want to optimize the hall utilization, so probably about 30 minutes before the movie begins, all not consumed reservations are canceled. Users may buy a ticket in a couple of ways - online using a desktop or mobile, directly at the cash desk, or in front of the vending machine.
Moreover, some pay for tickets, while others have a subscription to your cinema. What if there is a technical problem and the show is off? You may need to refund the money to your customers. And shows planning. Some movies are more popular, while others are less. It would be best if you considered it in the cinema's schedule. That all involves a lot of processes and rules. For such a system, DDD is a must-have.

Another situation when it's not worth it to involve DDD is when your software solves more technical than business problems. For example, think about the data encryption system. It's the software you may sell and earn money on it. However, it doesn't reflect any business processes. It's simply an implementation of an encryption algorithm. It doesn't make sense to overcomplicate it by using DDD patterns.

Summary

This article started by explaining what Domain Driven Design is. You already know that this approach to software design and development helps tackle complex domain problems. It defines strategic and technical patterns. This article explained what concepts stand for strategic parts:

• knowledge crunching, which helps to understand the business and its domain better
• dividing the domain into subdomains for better modularization
• prioritizing the subdomains to know what to focus on and what can be outsourced
• the ubiquitous language used across the whole organization to avoid cost translations
• cross-team collaboration for day-to-day cooperation, which supports understanding
• team relations which show the bottlenecks in cooperation

This article's main goal was to explain the benefits of using Domain Driven Design for leading a successful business. Now you know that:

• it ensures an alignment between business and development teams by introducing ubiquitous language and close cooperation
• a range of workshops invented or adopted by the DDD community improves the communication between people engaged in the project
• workshops also help to exchange knowledge between domain experts and development teams, which helps to craft software that addresses the real business problems
• it helps implement more flexible code, which can be quickly adapted to changes in the business area to increase competitiveness
• it helps to divide the big complex business into smaller parts and understand what to focus on and what's not really important for your company

All those benefits translate to the ones which boost your business:

• cost savings, as you know what subdomains are important and what is less. Also, you may notice the bottlenecks in team relations.
• profit increase, as you may optimize your staffing. Also, you know what areas really earn money and which are just supportive.
• faster time to market, as the design is ready for changes
• user happiness, as the system does what it's intended to do and what customers expect

Finally, I explained what are the situations when it's not worth using Domain Driven Design and in what cases it's a must-have.

I hope that after reading this article, you don't feel overwhelmed and lost in the Domain Driven Design landscape anymore, and as you understand the benefits of using it, you're ready to implement it in your company together with IT folks if it's worth it in your case.