While DDD is becoming more and more popular, there are quite a few potential misinterpretations and malpractices floating around. These issues are time-consuming, and they induce a lot of frustrations and needless yak-shaving experiences.
These pitfalls are plenty, ranging from higher level things (for example a lack of focus on the strategic part) to technical things (for example misinterpretations of the repository pattern), and even the surrounding area (for example errors made when"selling DDD" to your team members).
By sharing this experience I hope to reduce the huge amount of time and effort people spend on "doing DDD wrong".
19. Strategic Bounded contexts A lot Little
POV
Amount
Up- / Downstream A lot Little
Contracts
Dependencies
Some things that work *
* n = 1
39. Infrastructure
Anything: do you need it?
”Il semble que la perfection soit atteinte
non quand il n'y a plus rien à ajouter,
mais quand il n'y a plus rien à retrancher.”
Antoine de Saint-Exupéry
48. Strategic
• Don’t ignore bounded contexts
• Understand Conway’s Law
• Think first, act later
• Have domain experts
Craft BCs and make them explicit
49. Tactical
• Only in core domains
• Find all ways to model them
• Repositories = domain only
• Repositories = Tell, don’t ask
50. Infrastructure
• Don’t build a BDUF
• Frameworks <> libraries
• Avoid hacks
• Aim for simplicity, not ease of building