Domain Driven Design (DDD): Why You Need It

A powerful technical solution starts with an understanding of the big picture. Domain Driven Design is used to map the domains. In a 'Big Picture' session, where Domain Driven Design usually starts, domain experts from business and IT map out all the steps of an existing or an intended process and you work on the common understanding of those processes, variables, and concepts.

First of all, this is a fun session, in which you work with a pen and a stack of sticky notes. By visualising business processes with sticky notes, any bottlenecks across the various steps in the process or missing links become visible. And because you work closely with colleagues from other domains, it’s also very useful for your teams’ collaborations in the long term.

An example

Think of an animal hospital. Examples of domain experts from the business in this case are, for example, a veterinarian or an assistant. They can give you a lot of practical information, how are appointments scheduled? Or how are customers invited for their pet’s annual vaccinations? What does a treatment overview with its associated costs look like? Domain experts from IT can then map out the technical side. What systems are already in place? And how do the customers log in? This is a great way to create one joint overview.

The Big Picture session(s) bring domain experts from business and IT together and provide them with one vision, but we also often see that new insights arise. An example of a common issue in commerce is the integration between a Product Information Management system (PIM) and a webshop. A good PIM system ensures error-free, consistent, and up-to-date product information in your shop. You then have to deal with processes around PIM management, webshop management and data enrichment. The data from the PIM should also be published in the shop. Clear agreements about which system is responsible for what is an important topic. Thanks to the Big Picture Session and discussions with all the involved domain experts, bottlenecks are identified, and a clear understanding of processes is created. Software better matches reality and the actual needs of real users.

How does a Big Picture session within Domain Driven Design deliver value for software development? From our role as a digital partner, at iO we look at this as follows:

• Customer experience #1: by modelling software around domains, the user is put first, and you can create fluid digital journeys.

• Faster time-to-market and better cost efficiency: during development you always run into known and unforeseen issues. The later you identify issues, the more expensive it is to remedy. By using DDD to spar with domain experts from business and IT about their wishes, requirements, processes, and journeys, you can identify the most critical processes for the company at an early stage. By paying extra attention to this in the development process, development can be faster and more cost-efficient.

• Common understanding: by developing a clear language that is used by all domain experts, they become interlocutors and can better understand each other's starting points and interests. This can remove and demystify a lot of a project’s complexity.

• Scalable solutions: by discussing business objectives together, events and possible campaigns, can be planned for in detail, in advance. Systems can be designed to be able to cope with the peak load with Sinterklaas and Christmas campaigns, for example.

With Domain Driven Design we bridge the gap between the business and IT, by focusing on added value. Accurately mapping journeys and processes in advance and developing unambiguous definitions about them is a very powerful concept.

With this, the focus of application development shifts from focusing on a strictly determined technical issue, to the development of functionalities, with the necessary added value for a business model. This makes DDD ideally suited for more complex digital challenges, such as developing customised solutions for platforms or extending standard software. This often involves different domains across the chain, with the most important advantage being that development processes can run (cost) more efficiently.