《领域驱动设计》 第五章 软件所表示的模型（5.4 5.5 5.6）

模式：Service

有时，对象不是一个事物。

有些重要的领取操作是无法放到Entity或ValueObject中，因为操作本质上是一种动作，不是事务的一些具体体现，因为我们要划分相关领域范式，所以需要将这些相关的动作或者操作划分到这个对象中。

我们常见的错误是将一些不合适的动作强行的和对象融合在一起。

有些service名称看起来是模型对象，但是对于实际业务上没有任何关联性。

一些领域概念不适合以对象的形式去建模，去掉认为操作去增加无意义的模型。

service强调的是对象与动作的关系。领域驱动中的service与我们技术框架中的Service模式有着本质上的区别。

我们需要查分出针对某个领域独立部分。

1）领域概念相关的操作与Entity和Value Object有着本质的区别。

2）接口是根据领域模型的其他元素定义的（领域的规则，领域的业务）

3）操作室无状态的

操作要相对独立，可以适用于不同位置的调用。service中的操作尽可能作为独立的接口进行操作。

Service的功能在于区别应用层和领域层

区分领域层的Service和属于其他层的Service，划分规则，各司其职。

问题：应用层与领域层难以分割。

首先根据自己的业务确定出业务主线，业务主线中针对于数据流转的相关操作都应该作为领域层动作，而独立于数据操作的其他功能应界定为应用层功能。

针对两者拆分粒度，应保持再中等粒度，并且尽可能使用无状态的Service服务提高系统的复用性。过分的界定粒度可能会导致其他方面所带来的问题。

只有真正需要实现分布式系统或充分利用的框架功能才能设计出复杂的架构。

模式：Module

领域层中的Module需要关注两方面，一是Module中内部聚合关系以及细节，二是各个Module之间的关系。

Moudle应该是高内聚低耦合，不仅仅是代码上的拆分，也是概念的划分。

Module中的元素之间应该协同合作，有紧密概念关系的元素应该集中在一起。慢慢的模型会再内聚中找到更多的本质，来实现更深层次的抽象。

Module是一种表达机制，表达一个时段中发生的事。（不仅仅是本身的相关事务，也包括与本身相关的环境，因素等）。

敏捷的Module要保证代码和模型一起更改，两者相互相应，避免出现两者背离的情况。如果两者产生背离，那本身架构拆分将毫无意义。

代码发布隐患

对于代码分布在不同服务器中，否则实现单一职责概念对象的所有代码都应该在一个模块中。

利用带包可以将领域层代码分离出来，让领域开发人员自用决定打包方式，通过拆分不同模型来灵活支持设计。

不要再领域对象中添加任何与领域对象表示概念没有紧密关系的元素。

建模范式

目前最主流的建模范式是面向对象。

范式的意义是让非专业人员也可以理解，让模型借助工具再软件中表达出来。

建模范式依托于开发设计和设计文化的发展。

对象范式更适合对象性数据库。对象范式可以轻松地将对象表现出来但是内部的以来过于复杂，容易造成事务竞争问题。

拆分基础设施层，要针对细粒度进行决定，将紧密关联的对象进行解耦。

但是领域或者全局逻辑推理控制的领域不适合面向对象范式。（包括规则引擎）

领域模型不一定是对象模型

要尝试再多种范式中坚持使用Model-Driven Design

规则引擎是应用多种范式的例子，对象范式缺少表达规则和规则交互的具体语义。

使用规则的同事要考虑模型。所以要找到可以适用于不同范式的单一模型。

1）不要和实现范式做对抗，可以尝试别的方式考虑领域。

2）保证使用通用语言，保持语言使用上高度一致性。

3）保持怀疑态度。多个范式会使问题变得非常复杂。有些方式不是很优雅，但是却也可以解决问题。这是我们需要深思的问题。