Developers are introverts. Domain-driven design can help.

#ddd #softwareengineering #architecture #csharp

Developers are introverts. Domain-driven design can help to change it.

As developers, we are writing code to build software, but we can’t make good software without talking to clients.

Developers aren’t chatty.

Most of the time software developers are struggling in communication with clients and also with the outer world. Many of us choose this career to avoid meeting with people, and that is why companies hire managers who are doing instead of us.

If you are one of these introverts, then I have bad news for you. You may end up stuck with buggy code forever.

Developers are introverts. Domain-driven design can help. cover image — Created by rawpixel.com — [www.freepik.com](http://www.freepik.com)

If you are going to build software for business, you need to understand every detail because you are translating business processes into code. And you don’t want to lose important information in translation.

Domain-driven design intervention

One of the critical pieces of Domain-driven design(DDD) is to encourage developers for better interaction with domain experts. The domain expert is one who knows the client’s business needs and processes.

Developers need to understand their clients more than their partners. If you are a man, you probably are more successful in understanding your client than your precious one.

Photo by yanalya — [www.freepik.com](http://www.freepik.com)

You may say you already talk to them, but maybe in a different language. Maybe you are using your terms like tables in the database rather than domain concepts.

DDD guides us to find a common language with Domain Experts and understand each other at a much higher level.

Ubiquitous language

Ubiquitous. Terrible word. If you don’t know how to pronounce it, this might help [yo͞oˈbikwətəs]. For me, it doesn’t. I had to use Google Translator for listening to the pronunciation. It doesn’t help either.

A simple definition of a ubiquitous language is to come up with terms that will be commonly used when discussing a particular subdomain. What subdomain is, will be introduced in the next paragraph. Hold tight.

There will most likely be terms that come from the business space, not the software world. But those terms have to be agreed by both sides, domain expert and developer. Make sure there is no confusion or misunderstanding created by the terminology used by various members of the team.

Photo by pressfoto — [www.freepik.co](http://www.freepik.com)m

Domain and subdomains

The core domain is a field of study that defines a set of common requirements, terminology, and functionality for any software program. DDD teaches us how to divide the core domain into smaller subdomains.

Imagine a company. It can be divided into smaller pieces, departments, for example. With subdomains, the logic stays the same. They are filled with their complexity, terminology, tasks, and challenges.

Image by Starline — [www.freepik.com](http://www.freepik.com)

Many applications just try to do many things at once and introducing new features getting more difficult. With DDD, you will divide and conquer. By tearing software to separated subdomains, we can achieve dividing problems that are much easier to solve.

The principle of Separation of Concerns(SoC) not only plays a critical role in identifying the subdomains but within each subdomain, we use it as well.

Many applications spread domain logic across the entire project. Across the persistence layer, across the user interface. Such spreading makes it much more difficult to keep all of the business logic consistent.

If you want to keep going on the meta-skill side of building software — I'm publishing short, free lessons in The Claude Code Memory Starter, a tiny email series you can join in one click.

DDD applies an SoC to help direct you by focusing on the domain. Not on details like how to persist data into the database or how to connect to external API. Those become implementation details that you can ve worry about later.

Benefits

The first main benefit is flexibility. Because DDD guides us to focus on small, individual nearly autonomous pieces of our domain, our process and the resulting software is more flexible. We can easily move or modify the small parts with little or no side effects. The project is stable and flexible.

Image by master1305 — [www.freepik.com](http://www.freepik.com)

Another benefit is that code is closely mapped to the customer’s understanding of the problem. DDD gives you a clear and manageable path through a very complex problem. When you look at the code, you can see that it’s generally well organized and business logic all lives in one place.

DDD is not a path for every project, but there are many principles and patterns from which you can benefit. Its real benefit is for complex domains. You can describe domain as complex when it gets challenging to domain experts to express their needs. You know. Like women.

Image by Jcomp — [www.freepik.com](http://www.freepik.com)

DDD provides principles and patterns that help us tackle difficult software problems and even business problems. These patterns are historically successful in solving very complex problems.

The ultimate goal is not to write code, not even building software, but to solve problems. Nobody wants your software; they want what it can give them.

Disadvantages

You will spend a lot of time talking about the domain and the problems that need to be solved. And you will spend plenty of time sorting out what is truly domain logic and what is just infrastructure.

DDD is not always the right path for your applications. And it’s helpful to keep in mind that exist some scenarios where DDD is an overkill. If you have an application or subdomain that is just a data-driven app and doesn’t do much more than a lot of crud logic, there is no needs to use DDD. It would be a waste of time and effort.

Technical complexity doesn’t mean business domain complexity. DDD may not just be a path because your project is technically challenging.

The Book

DDD was presented in 2003 by Eric Evans in a book titled Domain-Driven Design. The book was written for one major reason, and that is for solving complex problems. That’s why a subtitle of Evans's book is “Tackling Complexity in the Heart of Software”.

Summary

Domain-Driven Design helps man to understand women fully. No. I am joking. One book could not be enough.

What I want you to take with you is this. Be more chatty with your clients and always try to understand their needs. If you don’t understand each other, define your ubiquitous language.

Divide and conquer your business logic. Separation of Concerns, loose coupling, subdomains. So many titles for one thought. Divide your code into smaller pieces on every level.

Daniel Rusnok's Newsletter

Every month I will send you an email about with list of my newest articles. It will be ofcourse the friendly links…www.danielrusnok.com