Domain driven design DDD-什么是复杂域？

人们常说DDD（领域驱动设计）更适合于复杂领域，而不是简单领域

复杂领域的特征是什么？（请比“it有复杂的业务规则”更具体）

哪些是复杂领域的例子

---

我如何将一个域划分为复杂域（即适用于DDD）或不复杂域？

根据我的经验，使您的域复杂化的三个最重要的因素是：

大小

大型域往往会增加复杂性。处理和协调很多事情总是很困难的

规则和不变量

域（甚至只有几个有界上下文的域）在其用例和过程中可能有许多域规则和不变量和/或许多细微差别。这增加了复杂性。对实体或域间事件中的大量更改进行垃圾邮件处理的规则通常是复杂的业务规则

上下文

上下文复杂性很难用一个例子来解释。让我们在表中输入与名为

Product

的实体相关的上下文复杂性

根据上下文；实体在您的域中可能意味着不同的事物。

产品

实体对于工厂上下文、营销上下文、销售上下文、售后支持上下文等并不意味着相同

---

如果与

产品

实体相关的数据、用户案例、流程、行为等在每个上下文中都非常不同，那么即使只有少数上下文和实体，复杂性也会增加很多。这通常意味着您有许多

产品

实体（每个上下文中都有一个），即使它们都由同一个持久性存储（对于ER存储，是同一个表）支持。

复杂性没有唯一的定义，但Vaughn Vernon book（）中有一个有用的描述：表1.1 DDD记分卡

---

他用不同的标准来描述这个项目，例如：一个复杂的项目经常会发生变化（新的特性，很难预料），你不完全理解这个领域（或者你需要与业务专家讨论很多模糊性），大小如@jlvaquero所说（特性/规则的数量/语言的丰富性…。

在我看来，复杂领域的一个标志是创建和维护无处不在的语言的难度

---

随着词汇、短语和术语变得越来越多样化，UL的创建变得越来越困难。这证实了该领域的复杂性。

我想说的是，这不仅适用于复杂领域，也适用于旨在延长寿命的雄心勃勃的项目。第二种说法忽略了复杂性。