Domain-driven design meets requirements engineering

The increasing complexity of software systems calls for approaches that are new, modern and different. Domain-driven design is thus gaining more and more attention, as this approach is much more than just an aid for developing microservices.

Though domain-driven design is an approach for designing software architectures, it also offers a lot of potential in requirements engineering, a point which is made particularly clear by the following quote from Dr Ute Heimann: ‘The technical task is the longest-lived and most important part of a system. The software must focus on this task and only solve technological issues with secondary priority.’

At this point at the latest, good requirements engineers should be paying attention.

What is domain-driven design

Domain-driven design offers a methodology in which domain experts and developers design the subject matter together. The subject matter becomes the object of close, mutual cooperation, as the project’s primary focus is on the domains as well as their domain logic. Instead of technological decisions, the subject matter moves to the centre of the software development process. In the process, technical issues are deliberately separated from technological decisions.

The main goal of the approach is to foster creative collaboration between technical and professional domain experts in order to iteratively refine the conceptual model. It is a procedure that stringently enables the modularisation of software on the basis of subject matter by dividing comprehensive systems into self-contained units (bounded contexts) and linking the code with the subject matter. This approach offers excellent opportunities to deal with this complexity appropriately, especially when it comes to the increasing complexity of software systems.

Complexity also demands organisation. Domain-driven design addresses this issue by defining methods for reflecting on the relationships and dependencies between the software modules as well as the teams performing the implementation.

Event storming – tidying up messy logic

Event storming was invented by Alberto Brandolini in the context of domain-driven design and is an interactive workshop that aims to bring together software developers and domain experts in order for them learn from one another and work together to design a domain’s logic.

But event storming is not widely known in the requirements engineering community although it is a very simple brainstorming method for quickly getting an overview of the entire business process to be mapped in the software. It is also a method that is extremely well suited to gathering and analysing requirements, as it does not require any modelling knowledge and hardly any preparation is needed.

With event storming, first, all relevant business events (events) are brought together and put in the right order. Care is taken at an early stage to ensure that all participants speak the same language. Homonyms and synonyms are identified and standardised. Then, an analysis is performed to determine what has to happen for an event to occur. This can include things such as user commands, sets of rules or a decision from a third-party system. Business processes, data objects, aggregate data and the required information on the user interfaces (view models) can be derived using this information as a basis.

The events and their triggers are clustered into different areas and grouped into domains and subdomains, at which point the timeline can be disregarded. The bounded contexts as well as connecting contexts and contextual dependencies can then be defined based on the subdomains. The result is the basis for the domain model as well as for an initial software design.

Event storming also enables the early identification of risks, strangely designed business processes and gaps in expertise. All critical areas, key features, risks and opportunities for improvement are marked accordingly. That way, there are no surprises afterward.

This gives the system a good, maintainable structure, and the number of refactorings is lower than it would be without the knowledge acquired in the event storming process.

How can a requirements engineer lend support for the domain-driven design approach?

Dr Ute Heimann’s quote makes the answer pretty obvious: the focus is on the subject matter, not the technology. As a result, requirements engineers are able to familiarise themselves with the approach, even without a deep technological background, and lend excellent support.

In their normal day-to-day business, this role works closely with experts to identify and record objectives and business requirements. Requirements engineers are also tasked with creating a context overview and defining the contextual boundaries.

By familiarising themselves with the core concept of domain-driven design, this role is able to create the domain model together with the architect and use the patterns and principles of domain-driven design to model the domain logic. In doing so, the requirements engineer can ensure that the design is aligned with the business objectives and meets the project’s requirements.

This role can also help define the ubiquitous language by creating a glossary so that the entire team understands and speaks the language.

Event storming is becoming part of a requirements engineer’s standard methodology in order to ensure that the approach taken is aligned with domain-driven design right at the start of the project and that our clients are trained in it and understand the principle of domain-driven design.

A requirements engineer is also responsible for structuring the project, for example, in the form of epics and features as well as story maps. The identified domains should be reflected in it so that everyone participating in the project sees a uniform structure in the various artefacts and understanding of the domain model is promoted.

Conclusion

Domain-driven design has a lot of potential as regards keeping track of complex and extensive projects and clustering them into manageable units. By familiarising themselves with this approach and adapting their project tasks to it, requirements engineers can make a valuable contribution to getting to the root of complex technical contexts and developing a well-designed system and a well-designed architecture.

You will find more exciting topics from the adesso world in our latest blog posts.