人们常说DDD(领域驱动设计)更适用于复杂的领域而不是简单的领域。
什么特征构成一个复杂的领域?(请比"它有复杂的业务规则"更具体)
哪些是复杂领域的例子?
如何分类一个领域是否为复杂(即是否适合DDD)?
人们常说DDD(领域驱动设计)更适用于复杂的领域而不是简单的领域。
什么特征构成一个复杂的领域?(请比"它有复杂的业务规则"更具体)
哪些是复杂领域的例子?
如何分类一个领域是否为复杂(即是否适合DDD)?
根据我的经验,让您的域变得复杂的三个最重要的因素是:
规模
大型域往往会增加复杂性。处理和协调许多事情总是很困难的。
规则和不变量
域(即使只有几个有界上下文的域)可能具有许多领域规则和不变量以及/或其用例和过程中的许多细微差别。这增加了复杂性。在实体或跨域事件中涉及大量更改的规则通常是复杂业务规则。
上下文
上下文复杂性很难在没有示例的情况下解释。让我们将与名为Product
的实体相关的上下文复杂性放在表格中。
根据上下文; 实体在您的域中可能意味着不同的事情。对于工厂上下文、营销上下文、销售上下文、售后支持上下文等,Product
实体的含义并不相同。
如果与Product
实体相关的数据、用户用例、流程、行为等在每个上下文中都非常不同,则即使只有少数上下文和实体,复杂性也会大大增加。这通常意味着您拥有许多Product
实体(每个上下文一个),即使所有这些实体都由相同的持久性存储支持(在ER存储的情况下,是相同的表/ s)。
复杂性没有唯一的定义,但在 Vaughn Vernon 的书(实现领域驱动设计)中有一个有用的描述:表1.1 DDD评分卡。
他用不同的标准描述了项目的复杂性,例如:复杂的项目经常会发生变化(新功能,很难预测),您不完全了解该领域(或存在许多需要与业务专家讨论的模糊点),大小如 @jlvaquero 所说(特性/规则数量、语言的丰富程度等)。