Stop me if you’ve heard this one before.

A developer walks into a requirements review and after a few minutes says “But this is just like part of the application we wrote 6 months ago.”

The lead says “Can we reuse that code?”

The dev says “It would take longer for us to abstract it than to just rewrite it. It’s in there with other functionality specific to that app.”

And no one laughs. We’ve all been in this meeting, felt the frustration bubble up. The business doesn’t understand why it will take so long to build. The IT leadership is shaking their heads because we’re not able to leverage what’s already been built. And the developer is grinding their teeth at having to solve the same problem, again.

For those of us with experience and background in software development, we know this isn’t how it’s supposed to work. What happened to breaking problems down, building re-usable objects, abstracting functional layers?

There are lots of reasons good development practices fall to the wayside. Lack of understanding of the business problem, crunched timeline, and budgets are all excuses for setting aside properly engineering a solution.

Domain-driven Design would like to change that. It’s not a methodology, like Agile, or a process like RUP (Rational Unified Process). Instead it “provides a structure of practices and terminology for making design decisions that focus and accelerate software projects dealing with complicated domains.”

Like all tools, DDD has a time and a place. But when used in the right context, at the right time, and applied correctly it can bridge the gap between the business and developers and lead to efficiency in enterprise development.

What is Domain-Driven Design?

DDD was introduced by Eric Evans in 2003 in his book of the same name. In it, Evans outlines a systematic approach to understanding complex business problems and applying domain models to those problems to create organized and focused solutions.

The intent, of course, is to build better, more re-usable, more cost effective software, especially in the face of highly complex business systems. Evan’s approach enables developers to better understand the business problem and communicate more effectively with their business counterparts.

It is also intended to help developers to better size down problems and fence in what they are building. As the old saying goes, you eat an elephant one bite at a time. But thanks to the evolution of software solutions and network computing, those bites speak to modern software architecture.

As enterprises continue to adopt and adapt to software services, having an approach that maps out how to break a business need down into service, and even microservice components that become useful and re-usable. But starting with services encourages a bottom-up design.

DDD, on the other hand, starts at the top. It directs teams to create a common language with the business before solving the business problem. To understand how it does this, let’s look at the basics of DDD.

DDD 101

Clearly, the first thing to understand with Domain-Driven Design is to define what we mean by a domain.

The domain is, basically, the business area we’re talking about. It’s the area of the business relevant to the solution needed, and to help you define and find your domain experts.

Are you talking about a new CRM? You’ll want someone from sales. New call center software? You’ll want a call center manager. A new CAD system? Bring in an engineer.

What you want is someone with a business understanding of the problem you’re trying to solve with a software implementation. That’s your domain expert.

But a common problem with humans in general, and in business to IT communications, is making sure you are all speaking the same language. That’s where the next step of DDD comes in – creating what Evans calls a Ubiquitous Language.

This will be the cornerstone of communication for everyone who works on the project. It will define the language the team will use to talk about the project. And it will evolve and grow over time, through trial and error.

For instance, if you were asked to build a car, you might think “sports car” while the product manager means “family sedan”. So you define that, for the purposes of this project and this domain, “car” means “family sedan”.

It’s a bit of a contrived example, but you can see where not having that definition in place would lead to some costly trouble.

Once everyone is speaking the same language, developers can break down the domain into smaller sub-domains and bounded contexts. A bounded context is like a miniature application, and has its own domain.

Think of an eCommerce system. By itself, it is a context – one where people use the application to shop. But, within that context lie smaller domains, like customer information, payment processing and inventory. Each of these is a bounded context, with one domain.

There is more detail within Domain-Driven Design, much of which is outside of the scope of this article and begins to dive into more technical nitty-gritty.

But the above describes how DDD begins to handle the parts of a project with the greatest potential for complexity – what the business needs are and how to build an understanding across the team.

Breaking the project down, bit by bit, allows the teams to develop highly modular pieces of code. Code that can be re-used. Code that can be refactored without upending an entire system.

Benefits to the Enterprise

The greatest gains to the business for DDD come from highly complex applications and domains.

First, the organization as a whole has a greater understanding of the domain, thanks to the need to model it for the ubiquitous language and bounded context.

The enterprise also creates a common language that can be used within the context of building out the solution, but can also be carried throughout the domain and the organization.

Better code can be created because the domain experts are an integral part of understanding the problem, and the solution.

The solution is better organized and focused thanks to the defined contexts.

The enterprise gains re-usable services that can be iteratively improved and changed without taking down entire business systems.

Not a Silver Bullet

But DDD is not a silver bullet that will solve every issue in your enterprise.

First, it can be overkill on smaller and less complex projects, or projects with a limited life span or usefulness to the organization.

And while building a domain model can be helpful in and of itself, it isn’t DDD, but only a part of it.
Domain models are time consuming to build and require resources from IT and the business. Likely from multiple business units.

There is much effort at the start required to define the domain, subdomain, contexts and ubiquitous language. And that means greater cost to the organization, up front. With the possibility of the return on that investment being months or years down the road.

Domain-Driven Design is an effective set of techniques for complex, enterprise level software projects that will have years of life within the organization. And principles of DDD, individually, have merit for the organization that is willing to commit resources early on. But just like holding a daily stand up meeting is not the same as implementing Agile, creating a domain map isn’t the same as following DDD.

And yet, for those projects that fit the mold, DDD is worth deeper investigation as a means of bringing greater understanding and more modular development.