Getting started with Domain Driven Design without fighting the wrong battles by Josian Chevalier

Learn the fundamentals of Domain Driven Design and how to successfully implement it in your projects without getting bogged down in unnecessary technical details, with this insightful talk.

Key takeaways

Domain Driven Design is not a framework, but a philosophy supported by a toolbox of patterns and practices.
The key is to have a deep understanding of the domain and the language used to describe it.
Without a clear strategy, you’ll focus on the wrong things, such as tactics without understanding the domain.
The goal is to create a model that is useful, explicit, and consistent.
A model is an abstraction of domain knowledge, and its evolution should lead to a deeper understanding of the domain.
A tactical pattern is a specific technique used to implement a pattern, and it is always close to the code.
Event Storming is a technique used to uncover the events and processes in a domain, and it should be done with the domain experts and developers together.
The model should be kept simple, and it’s better to have multiple simple solutions than one complex solution.
Communication is key, and it’s essential to have a deep understanding of the language used in the domain.
A partnership between teams is crucial, and it’s better to have a single team working on multiple contexts.
The tactical patterns should be used to isolate the business logic and keep it decoupled from the technology.
The model should be continuous, and it should evolve as the domain evolves.
The goal is to create a model that is useful, explicit, and consistent, and it’s essential to have a deep understanding of the domain.
A.Domain events should be identified and modelled as they occur.
The model should be refined over time, and it’s essential to have a deep understanding of the domain.
A.Clear boundaries are crucial in Domain Driven Design, and they should be established early on.
A.Navigator is an object that promotes communication between the application and the presentation layer.
The model should be kept simple, and it’s better to have multiple simple solutions than one complex solution.
A partnership between teams is crucial, and it’s better to have a single team working on multiple contexts.
The model should be continuous, and it should evolve as the domain evolves.
A.Domain events should be identified and modelled as they occur.
The model should be refined over time, and it’s essential to have a deep understanding of the domain.

Getting started with Domain Driven Design without fighting the wrong battles by Josian Chevalier

More talks