Mani mcoem

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 fulfil, 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, the more important it is to include all elements of that domain in the design and development process.

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.

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

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.

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:

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

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

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.