What is Domain Driven Design and how it can support product development

Looked at one way, your digital product consists of code. However, look at it another way and it’s obviously far more than that. The code in your app, platform, or website – essential though it may be – is just one part of a larger, more complex system, or “domain”. Your product’s domain is basically the subject area that your product addresses and/or operates within. It includes the user requirements the product aims to fulfill, the business goals it will contribute to, and the terminology used to describe and discuss it. The domain then influences more technical issues, such as programming languages, the devices and other hardware to be used, and of course, the programmed code, functions, and features of the product itself. The more complex the product and its domain are, the more important it is to include all elements of that domain in the design and development process.

What is DDD? Definition of Domain-Driven Design

When your design process is domain-driven, it incorporates a model of the domain in the process itself. A common approach is used by everyone involved in the product’s design and development, one that uses a common language and terminology, and a common understanding of just why the product is being built.

The concept of domain-driven design was first elaborated by Eric Evans, in his 2004 book, “Domain-Driven Design: Tackling Complexity in the Heart of Software”. Central to Evans’ book is the concept that not only do all those involved in the product’s design need a common language, that language should also be a fundamental part of the product to be built.

Put another way, domain-driven design is a system of collaboration, enabling technical and non-technical contributors (such as subject-matter experts) to communicate and understand each other, to the ultimate benefit of the product being created.

Domain-Driven Design: key terms

One way to find clarity on the ingredients of DDD is to focus on the core terminology, as follows:

• Domain model – The domain model contains everything, all the business concepts, data and information relevant to the problem your digital product aims to address.
• Subdomain – The domain model is divided into subdomains, each relating to a different element of the domain or issue that the digital product is addressing.
• Bounded context – The domain model (and subdomains) is a detailed and practical expression of the problem. The idea of DDD is that the solution (including the coding structure of your digital product) mirrors the problem. However, the more complex the domain, the more likely you will need to use subdomains. As an example, if your business involves selling a product, you might have two bounded contexts: sales and support, to reflect the two sides of your dealings with customers: before and after they have acquired your product.
• Domain logic – Also called ‘business logic’, this is a set of rules or norms that dictate the creation, storage and amendment of the data used by the product.
• Design pattern – Design patterns are previously-written pieces of code that address different elements of the issue your product aims to address. Break the issue down into its separate component challenges, and you’ll likely find that past design patterns can be used to solve many of them.
• Ubiquitous language – Every group of experts have their own jargon, their own expertise-related languages. In digital product development, a variety of experts come together; not only frontend and backend developers, but also quality assurance specialists, business analysts, subject-matter experts, and so on. Domain-driven design involves agreeing terminology and definitions that are then used in all aspects of the design and development process (including the code, which will also use ubiquitous language terminology) by all experts involved. Naturally, all agreed terminology is connected to the overall domain model in some way.

Why use a Domain-Driven Design approach?

Domain-driven design is an ideal route to a coherent and consistent design process. However, while it is potentially extremely efficient, it may be too much for simpler digital products – a case of using a sledgehammer to crack a nut.

DDD is best-suited to complex problems, or products that are expected to operate within and take account of a complex and varied business environment; i.e. numerous data sources, various interconnections between data, and multiple outputs.

Similarly, one of the goals of DDD is to bring the technical and business aspects of the design process together. Arguably, the more important the business goal which your digital product supports, the stronger the case for using a domain-driven approach.

Finally, with a large and varied design team and stakeholder group, the common language that results from being domain-driven helps ensure clear communication and discussion in an environment in which misunderstandings could be fatal to your digital product.

Coding the complexities

So far, we’ve talked about how DDD organizes and impacts the design process, facilitating more efficient working between people with different backgrounds and competences. But the domain-driven design approach can also be applied to your digital product’s code, its architecture…

The issue is that in a complex domain, or a complex product, different elements interact and therefore interrelate – make a change to a business rule as part of your ongoing maintenance and updating and you could find consequences in how your user interface or database function, for example. The answer is always to create and maintain simplicity. As with the use of subdomains as a way of breaking a complex domain into smaller problems, in terms of your coding structure, the DDD solution is to use a layered architecture to manage complexities. Each layer is cohesive and is dependent on (i.e. requires data from, or is impacted by) the layers below. Put another way, higher layers refer to lower layers, but not the other way around. Eric Evans’ book recommends four layers:

• User Interface layer (or Presentation Layer) – displays information and data to users, accepts and interprets user input and commands.
• Application layer - coordinates the digital product’s activity, according to business rules though it does not itself contain the business rules.
• Infrastructure layer – supporting communication between the other layers and external services and resources (e.g. file system, cache, loggers, queues, email, search index, etc.), also handles storage and access to data.
• Domain layer – contains information about the domain, all the business rules and logic, and the business state (the current configuration of the system in a given moment).

Your digital product may not need all four layers, but if you’re taking a domain-driven design approach, the domain layer is essential.

Benefits of Domain-Driven Design

For complex applications, adopting a domain-driven design approach offers the following benefits for your design process:

• Improved communication – the ubiquitous language element makes for easier and simpler communication, especially between technical and non-technical members of the development team.
• Aligned to your business goals – with clarity and consistency on the intended business results of the digital product you are more likely to create a product that reflects how your business operates.
• Flexibility – with a layered and modular design, your product is easier to update, modify and modernize as the need arises, with less unintended impacts.
• User-focused – although the domain is more fundamental, and in a sense therefore more important, than the user experience or user interface, nevertheless by keeping the domain central in the design process, the result is a product that addresses the needs of users for whom the domain is most relevant.
• Efficiency – put simply, with the close (and comprehensible!) involvement of subject-matter experts, the product is more likely to do the job it needs to do, as opposed to the job a developer might think it should or could do; i.e. there’s less likelihood of it having features that nobody will use!

All that said, it must be acknowledged that DDD requires extensive domain expertise and input. This may sound obvious, but it can result in a lengthier (and therefore more expensive) design process. For complex products, or products operating in a complex domain, DDD is absolutely the most effective and efficient approach (especially when combined with an Agile methodology, such as scrum), but for simpler scenarios, well, it’s back to that sledgehammer and nut analogy.

Domain Driven Design summary

This article discussed what is DDD and its most important benefits. To sum it up, domain-driven design is a holistic approach to digital product development for complex products which require detailed and varied input from various sources of expertise, ensuring more effective cooperation through the agreement and use of a common language and terminology. DDD that works well to ensure the final product is fully aligned with your business priorities and goals, and targets those users most likely to benefit from it. Equally, the adoption of a layered architecture results in a technical design that is easier to maintain and upgrade, thus potentially extending the product’s life cycle. Domain-driven design isn’t the right choice of development approach for every digital product, but when it is, the results are invariably better.