。

分类标签来源于领域#xff0c;需要我们研究一些资料并做一些提炼。

从采用5W…领域模型的构建

发掘领域概念3种策略

2使用分类标签。

分类标签来源于领域需要我们研究一些资料并做一些提炼。

从采用5W法开始即事件What、原因Why、地点Where、时间When、人员Who之后在其上加以补充

一般情况下我们会从策略1开始组织中完全没有之前相关的旧系统的情况并不多见之后策略2和3结合使用

使用领域术语。

记住模型的首要任务是沟通使用领域专家熟悉和习惯的名字即使你认为有更精确的表达方式。

对于相同的名称但不同场景的情况应该将最易于识别的名字留给最常用的类型比如“订单”可以在支付场景和配送场景中使用

把它用在支付环节而不是配送环节因为支付环节更加的核心更符合这个名字的本身的含义业务逻辑也更复杂。

不要凭空创造概念或添加前缀和后缀来区分名称这只会增加沟通的障碍。

始终以领域专家和系统用户喜欢的方式进行沟通

创建关联

阅读导向箭头“►”是可选的它指示关联名称阅读的方向并不表示可见性或导航的方向

关联符号包含“0”时不管是“”“0…”还是“0…1”都客观上意味着这是一种可选关联并不一定发生

关联类允许将关联本身作为类并且使用属性、操作和其他特性对其进行建模。

使用关联类标准

1通用语言中就有关联类的概念如×××合同用来约束两个模型之间的关系。

关联简化

属性的3种类基本类型、通用的值对象和项目中的其他业务对象前两种类型一般写在类图框中而第三种使用关联来表达

使用方法

该操作的访问速度较慢。

为了避免线程阻塞甚至需要考虑为该操作提供一个异步版本那么将其建模为属性就可能导致开销过大。

该操作每次返回的值不同即使传入的参数不变。

比如Guid().NewGuid()方法每次都返回不同的值。

该操作返回一个集合。

返回集合的属性容易误导用户比如Employees和Addresses等属性就是不合适的。

使用属性建模时还有一些细节值得注意

2不要提供只写属性也不要让设置方法的存取范围比获取方法更广。

如果一个属性值没有获取的意义比如配置资源地址此时应该提供set方法而不是属性。

3要为所有属性提供默认值。

技术上默认值不会导致异常或安全漏洞业务上也往往体现一定的“默认”的领域含义

5如果属性设置方法抛出异常则要保留属性原来的值。

这在业务上也是合理的。

6不要在属性获取方法中抛出任何异常这会令人感到困惑。

如果确实存在这种可能性请改用方法

分配职责

在信息专家模式中职责分配给了具有完成该职责所需信息的模型。

信息包括模型的各种成员如字段、属性、关联以及对资源的可见性等。

如果一个对象能够承担相应的职责那么最好不要让更大的、具有更多信息的对象来承担这些职责

创建领域服务完成职责

如果一个职责需要的信息无法由一个模型提供应该怎么处理可以分为以下两种情况

当一个职责发现采用信息专家模式没有找到合适的模型时需考虑创建一个领域服务模型是否更好

1应使用类层次中最接近基类的类型来作为方法参数并保证该类型能够提供成员所需信息。

这样做可以使得方法的适用范围更广因为子类能取代任何基类的位置即子类可以传入以基类定义的参数但反过来则不行

2不要将指针、指针数组和多维数组作为方法的参数。

即使不在DDD团队中且代码要保证优秀可读性的场合指针和多维数组也是难以应对的。

可以对方法进行重新设计以避免使用这些类型作为参数。

3尽量不使用输出参数如out、ref关键字修饰的参数。

这会增加代码的复杂性给领域模型的验证和测试带来干扰。

同理尽量使用值对象而不是实体类型的参数因为值对象没有状态传入的是一个副本。

4可以使用重载Overload机制来简化方法的命名。

重载即模型拥有很多同名的方法但它们的参数不同根据传入的参数匹配对应的方法。

不要增加无谓的名称以减少沟通的难度。

使用重载机制让方法的命名更加顺畅。

触发事件

领域事件是一个特殊的模型成员。

领域模型状态的改变属性或者执行操作时达到某些判定条件都可能触发事件

领域事件是领域专家所关心的发生在领域中的有影响力的事件。

将领域中发生的活动建模为一系列离散事件每个事件都用领域对象来表示领域事件是领域模型的组成部分用于表示领域中所发生的事。

定义有两个层面一是纯业务层面领域事件来源于领域专家的通用语言具有业务含义二是设计层面领域事件可以建模为一个领域对象但这种对象是一种不可变类也就是值对象它将成为其他领域对象的一部分

事件的命名是过去时态事件的载体为类图其中包含的属性称为事件参数它们是该事件消费者需要的关于事件的信息

处理异常

异常处理是领域模型要考虑的一部分原因在于模型的责任不可能无限大。

在遇到自己处理能力之外的情况时要采用异常机制报告错误并将处理权转交。

异常就是这样一种机制某种程度上它可以保证领域模型的纯洁性让其只关注于核心逻辑而不用包含一堆意外情况处理代码

要使异常可序列化。

为了使异常能够跨应用程序和跨远程边界工作这样做是必须的。

要把与安全性有关的信息保存在私有的异常中确保只有可信赖的代码才能得到该信息。

比如数据库连接抛出的各类异常可能会泄露你的表命名、表结构等信息。

要为所有的自定义异常构建一份文档使开发人员能够掌握让他们能使用最合理、最具针对性的异常比如不要使用“集合超容”来描述“购物车已满”。

领域逻辑主要包括规则与约束、流程与分支、验证与筛选、算法与计算、时间与空间、有状态与无状态、同步与异步等

在模型中使用大括号{}来标记规则

当规则和判断条件众多时把这个约束提取到一个单独的方法中并用具有业务含义的名称来对其命名

约束既可以放在模型内部又可以单独将其提炼出来作为策略类或领域服务

相关规则在多个对象中出现造成了代码重复违反了“一处一个事实”原则。

很多领域逻辑是围绕这些约束展开的它的层级不适合下放到实体或值对象的方法中。

将约束单独作为一个模型可以避免重要的领域概念被淹没使通用语言更加顺畅

流程与分支

活动图对应的是协作图或时序图而不可能是类图它们展示了一个用例的参与对象以及对象之间传递的消息

协作图中的节点已经变成了各个领域模型其中的逻辑分支用中括号来标记如图5-32中的支付成功。

在业务流程图的基础上映射绘制出来的协作图不仅能交流业务还能直接指导实现开发是对流程与分支建模的最理想模型。

验证与筛选

规格模式是将一组判断条件封装成一个单独的值对象名称中一般带有形容词表达了很强的领域含义代表客户对于程度的看法如“大额存单”“过期发票”“优秀成绩”等。

如图5-34所示这个值对象会有一个是否满足的判断方法一般是IsSatisfiedBy()函数用于校验某个对象是否满足该规格所表达的条件只返回真假校验。

多个规格对象还可以灵活组装生成新的规格对象。

在业务逻辑上规格与约束的不同点在于约束是必须满足的而规格只是从集合中筛选或验证符合条件的成员

算法与计算

算法逻辑涉及领域的核心逻辑其本身往往是内聚的将其独立出来是最值得倡导的建模实践如复杂的候选人排名规则、销售佣金的计算策略、保单的风险评估等。

算法逻辑独立出来后避免了复杂算法对领域模型的干扰领域中的其他模型就可以专注于表达“做什么”的逻辑而把“如何做”的复杂细节转移给了算法模型

领域中的算法可以建模为算法对象常见于实时系统、科学和工程领域中。

如果算法需要的信息都在实体或值对象内部可以将该算法建模为该对象的操作。

但如果该算法内聚且明显独立于领域对象而变化那就不适合绑定一个领域对象要显式地将其建模为算法对象而不是隐藏在模型和代码深处。

算法对象声明关键字是标记在类图或协作图上以表明身份

算法对象经常会封装计算其算法所需要的数据这些数据可以是初始化数据、中间结果或阈值数据。

算法对象的主要职责是执行算法不要把任何业务协调职责放入其中

将算法封装为领域服务是最佳选项尤其是涉及多个实体类型、返回值为值对象的计算时。

1不给领域模型增加负担。

如果计算所需的信息超出了该对象的范围又会增加不必要的耦合。

2关于计算逻辑的领域概念变得更加清晰单独的计算规则一般都是核心域范畴单独出来可以增加通用语言的词汇。

建模为操作符重载

操作符重载就是让领域模型可以像基本类型那样进行加、减-、乘*、除/操作还包括等于、大于、小于等比较操作

当一个类内部出现public

static的方法时应该考虑该方法是继续放在这个类中还是单独成领域服务

时间与空间

1对于交互中的每条消息考虑其开始时间和触发周期。

将这个实时特征建模为消息的定时约束。

2对于交互中每个值得关注的消息序列考虑是否有一个相关的最大的相对时间。

将这个实时特征加为对该消息的定时约束。

把系统对时间的要求表示为约束{}并放在对应的消息旁边即可。

时间是动态逻辑只能展示在时序图或协作图上。

计时器对象是由外部计时器激活的控制对象。

计时器对象要么自己执行某个动作要么激活另一个对象来执行期望的动作

时效建模