Domain-Driven Design

Anyone preaches the virtues and advantages of domain-driven design, its positive impact on maintainability and adding features, and how it improves developer experience. However, as all things in life, all roses have their thorns.

Has anyone had any negative experience caused directly or indirectly by domain-driven design? This might be a botched migration, problems during the requirements gathering stage, domain models ending up being too rigid/too permissive for an application, etc.

cross-posted from: https://programming.dev/post/719255

Back Cover Text

The software development community widely acknowledges that domain modeling is central to software design. Through domain models, software developers are able to express rich functionality and translate it into a software implementation that truly serves the needs of its users. But despite its obvious importance, there are few practical resources that explain how to incorporate effective domain modeling into the software development process.

Domain-Driven Design fills that need. This is not a book about specific technologies. It offers readers a systematic approach to domain-driven design, presenting an extensive set of design best practices, experience-based techniques, and fundamental principles that facilitate the development of software projects facing complex domains. Intertwining design and development practice, this book incorporates numerous examples based on actual projects to illustrate the application of domain-driven design to real-world software development.

Readers learn how to use a domain model to make a complex development effort more focused and dynamic. A core of best practices and standard patterns provides a common language for the development team. A shift in emphasis—refactoring not just the code but the model underlying the code—in combination with the frequent iterations of Agile development leads to deeper insight into domains and enhanced communication between domain expert and programmer. Domain-Driven Design then builds on this foundation, and addresses modeling and design for complex systems and larger organizations.

Specific topics covered include:

• Getting all team members to speak the same language
• Connecting model and implementation more deeply
• Sharpening key distinctions in a model
• Managing the lifecycle of a domain object
• Writing domain code that is safe to combine in elaborate ways
• Making complex code obvious and predictable
• Formulating a domain vision statement
• Distilling the core of a complex domain
• Digging out implicit concepts needed in the model
• Applying analysis patterns
• Relating design patterns to the model
• Maintaining model integrity in a large system
• Dealing with coexisting models on the same project
• Organizing systems with large-scale structures
• Recognizing and responding to modeling breakthroughs

With this book in hand, object-oriented developers, system analysts, and designers will have the guidance they need to organize and focus their work, create rich and useful domain models, and leverage those models into quality, long-lasting software implementations.

In this conference talk, Evans explains some of the most important concepts related to Domain-Driven Design while taking a critical look at how we traditionally think about models. Suggests asking “which model would be more useful to solve this problem” instead of relying on our understanding of objects “in real world”. He also emphasizes the importance of communication with domain experts an use of ubiquitous language.

This reference gives a quick and authoritative summary of the key concepts of DDD. It is not meant as a learning introduction to the subject. Eric Evans' original book and a handful of others explain DDD in depth from different perspectives. On the other hand, we often need to scan a topic quickly or get the gist of a particular pattern. That is the purpose of this reference. It is complementary to the more discursive books.

This video shows a really nice and clear example of refactoring an anemic domain model into a rich one.

cross-posted from: https://programming.dev/post/140226

This is a fun way to explain how technical debt accumulates in our systems. Not having good understanding of the domain results in low code quality and difficult to maintain code bases.

After the talk, one of the contributors says "you are preaching to the converted." But we, engineers, need to learn how to communicate these concerns with the rest of the organization.

A good, short summary/definition of DDD.

Great talk on bounded contexts and microservices by Vladik Khononov

You don't get to laugh a lot while watching a conference talk on DDD. I highly recommend this very dynamic talk by Alberto Brandolini at DDD Europe. Event Storming and pineapple don't mix well.

This repository contains a collection of blog posts, videos and other resources for learning Domain-Driven Design. All resources are free to access.