Adopting domain-driven design at scale: Near enemies and how to defeat them

Everyone doing large-scale software delivery is using domain-driven design (DDD) these days, because it holds the key to delivering maintainable, evolvable solutions with independent teams. But it can go wrong, and then DDD is blamed. Andrew Harmel-Law and Gayathri Thiyagarajan detail a real project they saw fail. You'll learn the many problems they spotted and how they fixed them.

For the past decade and a half, DDD has been giving teams the tools to successfully tackle the complexity at the heart of software. But lots of people fail when they try to put its techniques and patterns into practice, especially at scale. Andrew Harmel-Law and Gayathri Thiyagarajan argue that the “near enemies” of DDD are to blame, things that look like DDD but are in fact counterfeits that push you further away from your goal. You’ll hear the real-life story of a large-scale DDD implementation gone awry. Andrew and Gayathri outline how they took stock of the situation, how they identified the near enemies, and how they defeated them and got everything back on track. Whether you’re working with serverless, microservices, or a more monolithic architecture (nothing wrong there), this fun talk is for those who want to learn the lessons of implementing DDD at scale with a healthy dose of pitfalls and hazards to watch out for too.