Architecture 何时应该真正使用DDD？何时认为DDD是一种过度杀伤力？

我需要一些关于何时可以/应该使用DDD和何时不能/不应该使用DDD的实际示例/比较？

与许多其他“好”编程实践一样，DDD关注实现最大增益，允许处理一些困难。根据我的知识和经验

DDD（使用大多数原则和模式以获得最大利益）可在以下情况下应用：

有必要支持大型和复杂的领域模型，其中包含困难的业务规则和大量的类

开发人员在OOP和DDD方面都有足够的技能。此外，每个从事项目工作的人都必须理解模型、领域知识和领域语言的重要性。整个团队应该“移动”到对领域更深入的理解，并正确地实施这些知识

开发人员拥有足够的技术技能，有机会专注于模型的实现方式

该项目被认为是长期的

项目业主（或经理）还应了解纳入DDD的额外成本及其好处

该项目使用面向对象作为主要的开发范式

DDD无效或不能应用于相反的情况

此外，DDD可能没有用处

小型和低质量水平的项目（如原型）

DDD的重要“部分”描述了适用于整个系统“内部”的模式和原则。因此，它与分布式系统堆栈无关（我不是指上下文映射和上下文绑定之类的模式，它构成了分布式系统的另一个“部分”）。因此，对于包含“简单单元应用程序”的高度分布式系统，应用DDD的这一“部分”是没有意义的（由于应用程序的简单性） 请注意，某些DDD原则可以应用于任何项目。例如，反腐败级别适合与外部或遗留系统集成。

+1表示“注意，某些DDD原则可以应用于任何项目”。我甚至可以说，大多数原则可以应用于任何项目。