Why You Might Fail With Domain-driven Design (Wordwide Software Architecture Summit 23)

Almost 20 years after the start of Domain-driven Design (DDD), the approach is widely used - but that is no guarantee that DDD projects will be successful. This talk will highlight typical mistakes, misunderstandings, and problems that occur with Domain-driven Design and in particular with Strategic Design. Of course, the presentation also discusses how to solve such problems , not just to avoid failure, but even to score a true success…
Presentation from Worldwide Software Architecture Summit by geekle. Thanks for providing the video!

[@jurgenfrei689]

I often feel that domain-driven design is highly valuable, and I completely agree with the concept. Assembling a team with experts in both technical details and understanding the business domain is extremely difficult. Sometimes, I wonder if it would be better to have only interfaces for communication, like Amazon mandates, and observe the outcome. This would avoid the complexities of the domain-driven design discussion. I find that in such discussions, it can either result in a technical design as you described or a distributed monolith, where services constantly call each other or rely on events in Kafka to maintain their data cache which brings its on challenges

[@szeredaiakos]

I have settled on a ..sort of 3D design. Which is usable in both system and application level. - Vertical slice are services or modules used by many. It is very much technology oriented with a lot of recomposition and it is mainly a layered system. - Depth. This is where adaptors, cache and network related code lives. This is overwhelmingly pipeline. - Horizontal slice. This is pure DDD. This is where 90% of problems get fixed. It is also the lattice where extensions mostly happen. If any of the services have constant issues or changes on one of their modules, that module should be transferred to the DDD axis.