Domain-driven design (DDD) learning resources

Introduction

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.

https://en.wikipedia.org/wiki/Domain-driven_design

DDD for everyone https://docs.google.com/presentation/d/1HOqF3vvvckDu05CgHwj7afZfbxrZrS62Mn3VpB0-T0w/edit#slide=id.p

Benefits

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

http://www.informit.com/articles/article.aspx?p=1944876&seqNum=4

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.

https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ee658117(v=pandp.10)

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."

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. https://dzone.com/articles/ddd-part-iv-ddd-amp-microservices

Glossary

Books

Presentations

References

Java

Ruby

Go

Samples

Java

Ruby

Go

Frameworks

(Actually "framework" is not important)

Java

Ruby

PreviousMicroservicesNextGo Programming Language

Last updated