domain-driven-design - 领域驱动设计——它在技术领域的相关性如何？

Question

关于 DDD，这是一直困扰我的一件事。在处理具有复杂模型的非技术业务领域以及技术人员和非技术领域专家之间需要大量交互时，我可以清楚地看到该方法的好处。

但是，当所讨论的“域”是技术性的时该怎么办？

例如，情况 A) 以一家网络初创公司为例。想象一下，他们正在尝试完成一些相当复杂的事情(例如 Facebook 克隆)，但几乎所有员工都是技术人员(或者至少具有很强的技术理解力)。

情况 B)怎么样？类似的情况，但项目雄心勃勃，并且一个孤独的开发人员试图创建具有优雅架构的东西。

我真的很想听听人们的看法。我真正想了解的重点是 DDD 的好处在哪里，可能有什么缺点，以及在什么时候一个比另一个更重要......

Answer 1

DDD 实际上只是 Fowler 在 Patterns of Enterprise Application Architecture 中调用域模型的设计模式的详细阐述。 。在那本书中，他将域模型与其他组织代码的方式(例如事务脚本)进行了比较，但很明显，除了最简单的应用程序之外，他更喜欢域模型而不是其他替代方案。我也是。

DDD 极大地扩展了域模型的原始概念，并为我们如何以对我们作为开发人员有利的方式分析和建模域提供了大量指导。

如果所讨论的领域很复杂，那么领域模型(以及 DDD)是一个不错的选择。域是面向业务的还是更技术性的并不重要。在他的书中Domain-Driven Design ，Eric Evans 首先描述了 DDD 技术如何帮助他对打印电路板应用程序进行建模。这肯定是一个技术领域(如果有的话)!

在我当前的工作中，我们使用 DDD 来建模处理基于声明的身份的应用程序 - 另一个非常技术性的领域。

DDD 实际上就是处理软件中的复杂性，这也是 Evans 的书的副标题:“解决软件核心的复杂性。”