Is Domain-Driven Design Overrated?
Year: 2021
Labels: domain-driven design, software architecture
Is Domain-Driven Design Overrated?
Speaker(s): Stefan Tilkov
Video URL: https://www.youtube.com/watch?v=ZZp9RQEGeqQ
Summary: The talk explains how Domain-Driven Design (DDD) is a good starting point but not something to be dogmatic about. DDD emphasizes building software with the domain as the central focus, the idea is to create a shared understanding between domain experts and developers through DDD key aspects. The speaker highlights DDD’s contributions, such as tactical patterns and strategic concepts, but also discusses its limitations - encouraging flexibility and the use of alternative approaches depending on the project.
Timestamps
00:00
- Introduction01:00
- What is Domain-driven design?04:30
- Key aspect #1: Ubiquitous language04:50
- Key aspect #2: Tactical patterns06:10
- Key aspect #3: Strategic design07:00
- Bounded contexts09:30
- Conceptual extensibility15:10
- Should design be domain-driven?26:30
- Revisit bounded contexts29:00
- Summary
Key Takeaways
- DDD has the idea that the domain model is the core of the software system (main concepts expressed in the model are visible in the implementation).
- Ubiquitous language refers to a shared, consistent vocabulary used by both domain experts (e.g., business stakeholders) and developers.
- Tactical patterns help structure code, while strategic design (e.g., bounded contexts) aids in managing domain complexity.
- DDD provides a set of best practices, patterns, and context relationships that should be a starting point and not rigid/fixed.
- Every design should be domain-driven (not technology-driven) and understanding the domain is key, but not every software needs to be built using a technology-neutral Object Oriented (OO) core.
- Alternatives to DDD can be: using an RDBMS, UX/UI-driven design that evolves from user experiments, using mathematical/functional models to generalize/abstract domain models, or be purely model-driven and create technology-independent models.
- Implementation strategy can differ depending on the bounded context of your project, e.g. OrderMgmt (bc) is UX-driven while Accounting (bc) is has a Relational strategy and Fulfilment (bc) is tactical DDD.
Questions/Discussion Points
- He mentions it's common among developers to have "domain allergy" i.e. preferring to explore cool technology to being bothered by learning domain concepts. I wonder if this has to do with personality, age - or is it generic? Can it be somewhat prevented through stronger product ownership?