Domain-driven design and agile development
Pulling Together
Domain-driven design (DDD) is a software development approach that develops a domain model – an abstraction of the behavior and data of a system – and refers to the entire design of the software, from the code level to the architecture, and the interaction of the development teams involved. For a consistent domain orientation to work, everybody involved needs to exchange information, especially technical experts and developers.
Ultimately, domain strategies can only form the basis of development if all stakeholders communicate them clearly; otherwise, only the subject matter experts have the required detailed knowledge of the domain – not the developers. This point is exactly where the first tie to agility can be found. One of the 12 principles of the agile software development manifesto includes: "Business people and developers must work together daily throughout the project" [1]. This arrangement is the only way to implement a domain-driven design.
Practice Instead of Theory
Initially, the DDD movement mainly encompassed ideas on structuring code or software systems. Discussing these with subject matter experts is difficult because they often lack the technical background to do so. Concepts like classes and modules are simply not general knowledge. However, it cannot be a prerequisite for joint work to first train subject matter experts in this area – the bar is simply too high. DDD, however, now includes a host of collaborative modeling techniques. The objective is to strengthen the understanding of the domain through joint work on artifacts that are not used directly to structure the software but serve solely to explain the domain in more detail.
Event storming is a well-known example of collaborative modeling, wherein everyone involved in the project uses sticky notes to create complex business processes
...Buy this article as PDF
(incl. VAT)