What is Domain Driven Design?

On the one hand, it can be seen as conceptual framework emerged from the work of Eric Evans and his famous blue book. On the other hand, we can think about DDD from much abstract perspective as software design whose main driving force is a choosen domain. In this text, I will focus more on second definition with brief explanation about first one.

Let’s first clarify what is domain, since this term can be found in both of this definitions.

Domain is a sphere of knowledge and main source of information for a software project.

If you are working in a financial sector, your domain will aggregeate knowledge about money, discounts, deposits, withdrawals, billing, invoices etc.

DDD as non-formalized software methodology (by Eric Evans) is made of two main parts:

• strategic
• tactical

Strategic part is concerned about different contexts, relations between them and language used to express domain knowledge. When I say language, I don’t mean programming language but more human language as a linguistic boundary around domain concepts. In DDD it is called ubiqoutus language. Strategic design is about communication and collaboration.

Tactical part deals with more practical aspect and the way domain is expressed in code. There is a common set of tools used by developers when implementing in a DDD style. These tools are:

• aggregates
• entities
• value objects
• services
• repositories

It is challenging to start DDD as code only, which is not surprise since most programmers are used to think about project from the perspective of their tools and programming languages.

Also, many programmers lack any kind of experience in jobs that are not code related.This appears to be source of failure for many projects. At the beginning it is not obvious, since it is usually important to have something implemented. When programmers think about project they think about code. There are requirements, but their role is just to ensure that tasks have some kind of textual support.

This common habit of giving code first class role should be turned upside down, if we want to write software for people. Tools that encourage collaboration and communicatin based on domain knowledge should be favored. Implementation should follow language. In fact, implementation should be easily swapped with some other technical decision.

Domains are hard, there is complexity involved everywhere. You can’t work on medical software just by reading project manager tasks. You have to know who is going to use your software, how, when, why, where … Ideally, you have to talk with users, listen to their problems, requirements. Even non-formal relationship can be huge source of valuable insights into nature of domain. Go out and drink couple of beers with your client. I am sure that your software will reflect closely your domain.

You have to see things in context, which is not possible just by reading jira tasks. Your job as programmer should be to model, not to write code. Code is just artifact. Implementing clients domain can be considered more like creative process or art. This is not possible when using generic tools like frameworks or automated processes.

Communication based on domain language brings you closer to human aspect of software. You can understand your clients business and your client.

I think that we are witnessing revolution in industry, in which primary goal of writing software will be again to address users. It sounds weird, but I think that not many projects really care about users. They think they care.

There is a lot of writings online on topic why software industry has failed to deliver what users wants. Lot’s of this is related to artificial separation between programmers and business people (or doman experts). We don’t now why it is like that, but we can see products of such approach, in the form of applications that don’t reflect business. In fact, most application looks like their business model is invented by developers. And they all look similar.

DDD is a new promise land that has some great ideas. Future looks much brighter if you as programmer approach your job as creative process, not just as exercise for your typing skills.