Domain-driven design (DDD) helps teams shape software around business distinctions that matter. As a product and organization grow, an old model can become an obstacle: rules are hard to find, changes affect unrelated features, and splitting team ownership does not by itself remove software coupling. section 10.4 section 12.5
When one model no longer fits
Vinted expanded from women’s clothing into other marketplace categories, but core abstractions still assumed that original vertical. At a gigs platform entering new markets, company and contact rules differed between Germany and the Netherlands. In each case, modeling distinct business needs became part of making change easier. section 10.4 section 12.5
A practical DDD effort can proceed in small, collaborative steps:
- Bring engineers, product colleagues, designers, and domain experts together to refine terminology and domain boundaries. section 17.1.1
- Choose a manageable flow for EventStorming before tackling a more complex model. The gigs-platform teams began with company onboarding. section 12.5
- Use the resulting model to guide a bounded context with rules suited to its domain, rather than assuming that a new team boundary has already decoupled the software. section 12.5
Figure 12.27 The software design EventStorming, showing the flow of a contact person in Germany registering on the platform and how that flow should be integrated with the current IDP (identity providers)
The software-design EventStorming figure traces German contact registration and its integration with existing identity providers, connecting a domain flow to an intended software model. section 12.5
DDD is also a learning practice, not just an architecture decision. At PayFit, a biweekly engineering book club widened to include product, design, and domain experts; participants refined boundaries and terminology for areas including time planning and payments. Start where shared understanding can improve a real change, then refine the model as teams learn. section 17.1.1
