Patterns, Principles, and Practices of Domain-Driven Design

9 Common Problems for Teams Starting Out with Domain-Driven Design

WHAT’S IN THIS CHAPTER?

• Understanding why Domain-Driven Design is about more than just writing code
• Avoiding the trap of overemphasizing the tactical patterns
• Why incorrectly applying Domain-Driven Design will make simple problems more complex and frustrate teams
• Realizing that strategic design, collaboration, and communication are more important than the Domain-Driven Design pattern language
• The wasted effort of teams not focusing on the core domain
• The pitfalls teams fall into when applying Domain-Driven Design without a domain expert or an iterative development methodology
• The antipattern of striving for Domain-Driven Design perfection

Domain-Driven Design (DDD) is a philosophy born out of a need to realign the focus of development teams writing software for complex domains. It is not a framework or a set of predefined templates that you can apply to a project. Although there is value in design patterns and frameworks, DDD emphasizes the value in collaboration, exploration, and learning between the business and development team to produce useful and relevant software. Teams should embrace the problem domain they are working within and look outside of their technical tunnel vision. The most fundamental point to being a great software craftsman is to understand the problem domain you work within and value this as much as you value your technical expertise.

Teams new to DDD or those that do not understand ...