《领域驱动设计精简版》

data modeling 数据建模
object modeling 对象建模

失血模型
贫血模型
充血模型，

领域驱动设计精简版

领域驱动设计： 现实中具体的领域， 比如银行系统， 驱动软件系统设计。

提取一个领域的基础知识

、
领域专家和软件专家， 开发出一个通用的领域模型
不拘泥于表达形式： 可以是 画图， 也可以是uml， 也可以是文档

模型驱动设计

模型驱动设计.png

image.png

最好能让应用中的领域部分尽可能少地和其他的部分掺杂在一起，因
为一个典型的应用包含了很多和数据库访问，文件或网络访问以及
用户界面等相关的代码。

模型驱动对象： 用模型来驱动对象。

image.png

领域层应该关注核心的领域问题。它应该不涉及基础
设施类的活动。用户界面既不跟业务逻辑紧密捆绑也不包含通常属
于基础设施层的任务。在很多情况下应用层是必要的。它会成为业
务逻辑之上的管理者，用来监督和协调应用的整个活动。

实体

有一类对象看上去好像拥有标识符，它的标识符在历经软件的各种
状态后仍能保持一致。
在软件中实现实体意味着创建标识符。
实体在领域模型中是必需的对象。

值对象

我们对某个对象是什么不感兴趣，只关心它拥有的属性。用来描述领域的特殊
方面、且没有标识符的一个对象，叫做值对象。
没有标识符，值对象就可以被轻易地创建或者丢弃。没有人关心创
建一个标识符，在没有其他对象引用时，垃圾回收会处理这个对
象。这极大简化了设计。

一条箴言是：如果值对象是可共享的，那么它们应该是不可变的。
值对象应该保持尽量的简单。
如果需要改变值对象， 创建一个新的值对象。

值对象可以包含其他的值对象，它们甚至还可以包含对实体对象的
引用。虽然值对象可用来简化一个领域对象要包含的属性，但这并
不意味着它应该包含所有的一大长列的属性。属性可以被分组到不
同的对象中。被选择用来构成一个值对象的属性应该形成一个概念
上的整体。
一个客户会跟其名称、街道、城市、州县相关。最好分
离出一个对象来包含地址信息，客户对象会包含一个对地址对象的
引用。街道、城市、州县应该归属于一个对象，因为它们在概念上
属于一体的，而不应该是作为分离的客户属性。

服务

但是有些领域中
的动作，它们是一些动词，看上去却不属于任何对象。它们代表了
领域中的一个重要的行为，所以不能忽略它们或者简单的把它们合
并到某个实体或者值对象中。给一个对象增加这样的行为会破坏这
个对象，让它看上去拥有了本该属于它的功能。
例如，为了从一个账户向另一个
账户转钱，这个功能应该放到转出的账户还是在接收的账户中？感
觉放在这两个中的哪一个也不对劲。
当这样的行为从领域中被识别出来时，最佳实践是将它声明成一个
服务。

以下是服务的 3个特征：

1. 服务执行的操作涉及一个领域概念，这个领域概念通常不属于一
   个实体或者值对象。
2. 被执行的操作涉及到领域中的其他的对象。
   3.操作是无状态的

领域对象的生命周期

聚合是一个用来定义对象所有权和边界的领域模式。工厂和资源库是另外的两个设计模式，

3） 资源库
如果这个对象是聚合的根，那么它是一个实体，它会被保持到一个被持久化
的状态，可能是在数据库中，也可能是其他的持久化形式。如果它
是一个值对象，它会通过一个实体经由对关联的导航来获得。我们
可以推导出大部分的对象可以从数据库中直接获取到。这解决了获
取对象引用的问题。当一个客户程序需要使用一个对象时，它可以
访问数据库，从中检索出对象并使用它。这看上去是个非常快捷并
且简单的解决方案，但它对设计会产生负面的影响。

模型、领域、 代码设计

模型现在已经跟它所源自的领域紧密关联了。我们也已经说过代码设计应该
围绕模型展开，模型自身也会基于设计决定而有所增进。

代码设计应该围绕模型开展；
domain翻译过来就是领域；