Sometimes, software design experts get into confusion when to and when not to use domain models. The following points might help you get an insight into DDD for efficient decision making and decide to implement DDD or not:

• Business cases and requirements are particular, specific to domains, and not related to technology implementations
• As an independent team, they wanted to go to DDD when:
  • The team has never done earlier that sort of business cases
  • The team need help from domain experts
  • The business cases are more complex
  • The team need to start from ground zero, and there are no previous models exists
• When the given design problem is important to your business
• Skilled, motivated, and passionate team to execute
• Have greater access to domain experts who are aligned with product vision
• Willing to follow iterative methodology
• Nontrivial problem domain that is critical to business
• Great understanding of vision
• Business goals, values, success and failure factors, and how is it going to be different from earlier implementations

To summarize, this chapter has short introductions to core principles, characteristics, and best practices for a team to get a head start and adopt DDD. Then, we introduced strategic patterns such as ubiquitous language, domain, subdomain, core domain, and bounded context in detail. We also covered the most essential aspects of DDD, such as autonomous bounded context, shared nothing architecture, single responsibility codes, multiple bounded contexts, and a bit of thought process about SOA principles concerning DDD aspects as part of integrating bounded contexts. We also saw the bubble context, autonomous bubble context, and expose as a service as part of the significant real-world problem of integrating with legacy systems. We introduced you to database integration, flat file integration, and event-driven messaging as part of distributed bounded context integration strategies.

As part of tactical patterns, this chapter covered entity, value objects, domain services, modules, aggregates, factories, and repositories and also discussed two emerging patterns: domain events and event sourcing.