Domain-driven design (DDD) learning resources
Last updated
Was this helpful?
Last updated
Was this helpful?
Domain-driven design (DDD) is an approach to software development for complex needs by connecting the implementation to an evolving model. The premise of domain-driven design is the following
placing the project's primary focus on the core domain and domain logic;
basing complex designs on a model of the domain;
initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.
DDD for everyone
DDD Value And Benefits (A.K.A. How To Sell Ddd To Your Management, Domain Experts, And Technical Team Members)
Organization gains a useful model of its domain
Develop a refined, precise definition and understanding of your business
Domain experts contribute to software design
Gain a better user experience
Place clean boundaries around pure models
Better organize elements of your enterprise architecture
Use agile, iterative, continuous modeling
Employ new tools, both strategic and tactical, to your code
The following are the main benefits of the Domain Driven Design style:
Communication. All parties within a development team can use the domain model and the entities it defines to communicate business knowledge and requirements using a common business domain language, without requiring technical jargon.
Extensible. The domain model is often modular and flexible, making it easy to update and extend as conditions and requirements change.
Testable. The domain model objects are loosely coupled and cohesive, allowing them to be more easily tested.
Consider DDD if you have a complex domain and you wish to improve communication and understanding within your development team, or where you must express the design of an application in a common language that all stakeholders can understand.
DDD can also be an ideal approach if you have large and complex enterprise data scenarios that are difficult to manage using other techniques.
In Microservices, we build each service to serve only one thing and do one thing well. Each service is also isolated from the others. On this matter, DDD principles can help us to keep the scope of the service small through what it calls "bounded context."
(Actually "framework" is not important)
)
Subsequently, DDD is going to help you investigate and know your domain and all subdomains well through the communication you build with the domain experts. By knowing your domain andsubdomains well, you will know the map contexts and how all subdomains interact with each other, which will help you in designing and choosing the type of your microservices architecture and what kind of approaches you use to implement them, whether a reactive approach, orchestration approach, or hybrid... it will depend on your knowledge about the domain you're working on. There are pros and cons for each approach that need to be evaluated based on the project and your domain knowledge. DDD will help you make a decision on this matter.
Greg Young — A Decade of DDD, CQRS, Event Sourcing
Eric Evans — Tackling Complexity in the Heart of Software
GOTO 2014 • Event Sourcing • Greg Young
Eric Evans - DDD and Microservices: At Last, Some Boundaries!
JDD 2017: Keep IT clean: mid-sized building blocks and hexagonal architecture (Jakub Nabrdalik)
Mariusz Gil: Discovering unknown with Event Storming
Boiling Frogs 2018 - Mariusz Gil - Discovering unknown domain with Event Storming )
WJUG #204 - Marcin Haręza: Event Sourcing - co to, po co to, jak to? (polish)
Domain Driven Design - A place for everything and everything in its place (polish)
Boiling Frogs 2018 - Jarosław Pałka - Sagi, strumienie, reaktywność i inne buzzwordy )
Sławomir Sobótka - DDD: Q&A - czyli co gryzie świadomego programistę/programistkę (polish)
Sławomir Sobótka - DDD Q&A - wersja rozszerzona (polish)
(polish)
Event-Driven Rails from scratch
DDD europe
(polish)
(polish)
(polish)
(polish)
(polish)
(polish)
(polish)
(event sourcing lib)