For too long Domain-driven design (DDD) has been sold as the ideal solution for very complex problems that only a few teams very actually writing. While technically correct, this statement sparked a number of misconceptions, the most important of which is that DDD requires an object model and must be agnostic of persistence and databases. At the end of the day, DDD is only an approach to the design of software system and is driven by the domain of the problem. The purpose of this talk is clearing the ground around DDD emphasizing the theoretical pillars of the approach: ubiquitous language and bounded context. From there, we’ll move ahead to creating a context map and then finally we’ll touch on the most commonly used supporting architectures for DDD: the popular Domain Model, CQRS and also event-sourcing. The key takeaway is that DDD is not for complex things; it is just a savvy approach for any software, including CRUD. (read more in the blogpost „DDD – a more modern view“ >>)

Requirements for participants: No need to bring a laptop. Blotting pads and pens will be available.
The workshop is articulated in four modules:

  • Conducting a domain analysis using DDD
  • CQRS and events for the common applications
  • UX-driven design
  • Persistence as just one aspect of infrastructure

The first module shows how some popular practices of DDD (Ubiquitous Language, Bounded Context and Context Mapping) help figuring out the ideal top-level architecture for the system being built. That produces a task-focused vision of the system in which most of attention is on workflows and chain of business events rather than data models. This inevitably brings towards the separation of responsibilities between commands and queries and possibly different stacks to carry each category of operations. This is the essence of CQRS and the use of events as the actual data source of the application adds more spice and power to the solution. The interesting thing is that this can be done step-by-step for just any application, including the common application. The ideal way to design such as a system is top-down rather than bottom-up as it’s always been the case for decades. UX-driven design (UXDD) just summarizes a few practices in a set of architectural prescriptions. Finally, the hardest shift to operate: moving from a mental model where it’s all about the data model to a model in which data is only part of the infrastructure required to implement tasks.