【发布时间】：2019-10-17 15:01:29
【问题描述】：
人们常说，DDD（Domain-driven Design）更适合复杂的领域，而不是更简单的领域。
复杂领域的特点是什么？ （请比“它有复杂的业务规则”更具体）；
哪些是复杂领域的例子？
如何将域分类为复杂（即适合 DDD）？
【问题讨论】：
-
我想说，这不仅适用于复杂的领域，也适用于旨在长寿的雄心勃勃的项目。第二个语句忽略了复杂性。
【发布时间】：2019-10-17 15:01:29
【问题描述】：
根据我的经验，使您的域复杂的 3 件最重要的事情：
尺寸
大域往往会增加复杂性。处理和协调很多事情总是很困难的。
规则和不变量
域（即使是只有几个有界上下文的域）在其用例和过程中可能有很多域规则和不变量和/或很多细微差别。这增加了复杂性。在实体或域间事件中发送大量更改的规则通常是复杂的业务规则。
上下文
没有一个例子很难解释上下文的复杂性。让我们将与名为Product 的实体相关的上下文复杂性放入表中。
取决于上下文；一个实体在您的域中可能意味着不同的事物。 Product 实体对于工厂上下文、营销上下文、销售上下文、PostSales 支持上下文等具有不同的含义。
如果与Product 实体相关的数据、用户案例、流程、行为等在每个上下文中都非常不同，那么即使您只有少数上下文和实体，复杂性也会大大增加。这通常意味着您有许多 Product 实体（每个上下文中都有一个），即使它们都由同一个持久性存储支持（对于 ER 存储，相同的表）。
【讨论】：
复杂性没有唯一的定义，但在 Vaughn Vernon 的书 (Implementing Domain Driven Design) 中有一个有用的描述：表 1.1 DDD 记分卡。
他用不同的标准来描述项目，例如：一个复杂的项目会经常变化（新特性，很难预料），你不完全理解这个领域（或者有很多歧义您需要与业务专家讨论），@jlvaquero 所说的大小（语言的功能/规则/丰富度的数量......）。
【讨论】：
在我看来，复杂领域的标志之一是创建和维护通用语言的难度。
随着词汇、短语和术语变得更加多样化，创建 UL 变得更加困难。这证实了域的复杂性。
【讨论】：