这是 DDD 困扰我一段时间的一件事。在处理具有复杂模型以及技术人员和非技术领域专家之间需要大量交互的非技术业务领域时，我可以清楚地看到这种方法的好处。
但是，当所讨论的“领域”是技术性的时候呢？
例如，情况 A) 以 Web 启动为例。想象一下，他们正在尝试完成一些相当复杂的事情（比如 facebook 克隆），但几乎所有员工都是技术人员（或者至少具有很强的技术理解力）。
情况 B) 情况类似，但项目的雄心略低，并且一个单独的开发人员试图创建具有优雅架构的东西。
我真的很想听听人们怎么说。我真正想要了解的是，DDD 的好处在哪里，可能的缺点是什么，以及在什么时候一个比另一个更重要......
DDD 实际上只是对 Fowler在企业应用程序架构模式中称为域模型的设计模式的阐述。在那本书中，他将域模型与其他组织代码的方式（例如事务脚本）进行了比较，但很明显，除了最简单的应用程序之外，他更喜欢域模型而不是其他替代方案。我也做。
DDD 只是对域模型的原始概念进行了极大的扩展，并为我们应该如何分析和建模我们的域提供了大量的指导，这对我们作为开发人员来说是有益的。
如果所讨论的领域很复杂，那么领域模型（以及 DDD）是一个不错的选择。域本质上是面向业务还是技术性更强并不重要。在他的《领域驱动设计》一书中，Eric Evans 首先描述了 DDD 技术如何帮助他为印刷电路板应用程序建模。那肯定是一个技术领域，如果有的话！
在我目前的工作中，我们正在使用 DDD 来建模一个处理基于声明的身份的应用程序——另一个非常技术性的领域。
DDD 实际上只是处理软件的复杂性，这也是 Evans 的书的副标题：“Tackling Complexity in the Heart of Software”。
Evans 建议在以下情况下使用领域驱动设计：
Domain Complexity > Technical Complexity
我真的没有给你一个很好的答案，但我可以说，作为对 DDD 感兴趣的 DDD 的局外人，我已经看到技术领域概念/驱动程序作为一流的概念潜入 DDD 对话。一个很好的例子是有些人提倡技术/基础设施有界的上下文。我能想到的最好的例子是Greg Young 的架构，他认为读取一个有界上下文，事务性写入另一个有界上下文。一般来说，我认为这样的事情是“域构造”（我的术语......如果我必须破坏一个真正的 DDD 术语，请原谅我）。这与 OO 世界中的对象类似，这些对象不会对现实世界中的某些东西进行建模，而是完全清除对象。