How Domain-Driven Design brings business value

Engineers often express the value of Domain-Driven Design (DDD) in the terms of engineering, and not in the terms of value to the business.

Unlike graphical design or user experience design, software design is invisible. This makes it hard to understand its value.

As a business leader, you might not be particularly interested in the idiosyncrasies of DDD: how to build a shared language, or how to organise domain models in bounded contexts. It’s not that this work fails to bring business value, quite the opposite, but we rarely express the value this can bring to the business and its goals. This ultimately prevents the adoption of DDD and the design techniques we believe can help organisations be successful.

Of course, if a software system is better engineered with the help of DDD, engineers will be more productive when developing it, which ultimately is beneficial for the organisation. But there are more direct ways that DDD brings business value. We’ll highlight a few examples here.

DDD focuses design effort on long-term business goals

DDD is a deeply pragmatic discipline. It recognises that design effort is a limited resource that should be deployed appropriately. DDD doesn’t impose hard rules for engineering everything to perfection. Instead, it says, let’s invest in better design where we believe it's advantageous. If we discover that, for example, a new component isn’t going to change much in the future, we will not invest in a more intricate domain model with more flexibility. Instead, that design effort will be directed to something that will benefit more, such as a “Core domain” (a business activity that moves the needle). Many other software design disciplines treat all software equally, pushing for a perfect design everywhere, without understanding the bigger context of that component.

When you want to build something productive for a long time, then this focus on design is incredibly helpful. A well-designed system (for a non-trivial business domain) remains maintainable, understandable, testable, and especially evolvable for as long as is needed. On many software projects, the pace of delivery slows down after 3 to 6 months. This is a direct result of bad design: people don’t understand the web of connections anymore, which they created by adding features indiscriminately. DDD advocates building models as part of the engineering work, and to evolve these models as new feature requests come along. These models are key to understandability and therefore evolvability.

DDD practitioners build models based on a deep understanding of the business needs. They see themselves as custodians of the relationship between the business goals, and the software system. As system designers, we look closely at the goals of the business. The models, and therefore the system, are designed not just to deliver features quickly, but to meet those long-term goals. We allocate design effort according to the expected impact.

DDD translates business strategy into software strategy

A core promise of Domain-Driven Design is the ability to translate business strategy into software strategy.

We love the adage “Your oldest code in your system should be your best code.” People are surprised by this statement: often the oldest code is the worst, most fragile code in the system. But if your business recognises that its core business is dependent on its oldest code, then good software design and strategy means focusing the most effort and best people on making sure the legacy code is clean, well modelled, and understood.

However the answer to a business strategy for software teams isn’t always technical excellence and marginal improvements. When the business has decided to discontinue a product line or shift focus to another offering, good software design and strategy wouldn’t continue to invest in codebases that will not have a major impact. If your business is in, say, B2B retail, then having a better homemade PDF generation tool won’t impact the bottom line. Having a well-designed pricing engine that can adapt to market conditions will.

Bounded contexts allow for fast experimentation

A bounded context is a boundary around a model and its language. DDD practitioners identify these boundaries to help them manage large, complex environments. Instead of trying to build a single model that encompasses the entire business, they identify areas that can be isolated. This allows the software designer to reason about a smaller area of the business, and evolve it without having to impact the rest of the software system.

Bounded contexts (BCs) help us isolate complexity. Let’s stick with the example of a pricing engine. We could model the entire pricing domain as a single concept. But on closer inspection, we could decide to separate the functionality that deals with supplier prices and margins, from the functionality for positioning our pricing against competitors’ prices. The margins BC is going to be quite stable: the percentages might change, but ultimately the notion of adding margins on top of supplier prices is not going to change.

The way we react to competitor pricing might change a lot though. We’ll need to adapt to new competitors, we’ll need to build new ways of scraping prices, react to campaigns… We’ll likely experiment with different strategies: for example, for some product categories, we could position ourselves as the premium provider, and keep our process above the competition.

Later, we may want to add new capabilities to our pricing engine, such as running pricing experiments to learn the ideal price point for a product. Again, we can separate the model (along with its logic, rules, and language) into a separate bounded context:

By separating it from the other responsibilities, we are much more free to experiment with this bounded context. We could change the model frequently, and figure out the best way to do this, without having to deal with the complexity of the other bounded contexts. This freedom will help us to find the best design quickly, the one that is most fitting for the business needs.

Having a good model of your system therefore enables you to move quickly. And a good model helps you make predictions about the behaviour of the system and helps you make predictions of how the system will behave in the future. And if you can change things fast, you can evolve things fast. You can experiment fast. You can innovate fast. You can get ahead of changes in the markets and achieve your goals.