领域驱动设计 - 技术领域的相关性如何？

Question

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

然而，当涉及的“域名”是技术时呢？

例如，情况A）采取网络启动。想象一下，他们正在努力完成一些相当复杂的事情（比如一个facebook克隆），但几乎所有员工都是技术人员（或者至少有很强的技术理解力）。

情况怎么样？B）类似的情况，但项目略显不那么雄心勃勃，还有一个开发人员试图用优雅的建筑创造出一些东西。

我真的很想听听人们说些什么。我真正想要的是，DDD的好处在于什么，缺点可能是什么，以及在什么时候比一个人更重要......

Answer 1

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

DDD只是对域模型的原始概念进行了大量扩展，并提供了大量关于如何以对开发人员有益的方式分析和建模我们的域的指导。

如果有问题的域很复杂，那么域模型（以及DDD）是一个不错的选择。域名是面向业务还是技术性质并不重要。 Eric Evans在他的书Domain-Driven Design中首先描述了DDD技术如何帮助他模拟印刷电路板应用。这肯定是一个技术领域，如果有的话！

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

DDD真的只是处理软件的复杂性，这也是埃文斯的书的副标题：“解决软件核心的复杂性。”

Answer 2

Evans建议在以下情况下使用域驱动设计：

Domain Complexity > Technical Complexity

• 如果您的域名很简单，但您有许多技术限制（技术选择，性能限制等），请不要使用DDD。
• 如果您的域名很复杂，请执行DDD，将域作为系统的核心，并将其他任何问题移到外面（持久性，性能，技术问题）。

Answer 3

我真的没有一个很好的答案，但我可以从我的角度说作为DDD的局外人对DDD感兴趣我已经看到技术领域概念/驱动程序在DDD对话中悄悄作为头等概念。一个很好的例子就是有些人提倡技术/基础设施有限的背景。我能想到的最好的例子是Greg Young's architecture他认为读取有界上下文并且事务写入另一个有界上下文。总的来说，我认为这样的事情是“领域结构”（我的术语......如果我必须肢解一个真正的DDD术语，请原谅我）。它与OO世界中的对象类似，它们不在现实世界中建模，而是完全冲刷出来的对象。