第七章 使用语言：一个扩展的示例
7.1 货物运输系统简介
文中
首先说明了该系统的3项基本功能。
而后利用模型将领域知识组织起来。
个人觉得最有意思的是：图7-1中货运领域模型的类图。
它描述了如何实现系统的基本功能，如何为将来可能发生的变化预留扩展空间。
7.2 隔离领域：引入应用层
应用层的职责是协调，它只负责提问，回答的职责交给领域层。
文中给了应用层的三个类：
货物跟踪查询【访问货物的过去、现在的变化情况】
预订服务【可以注册一个新的货物，并准备进行系统处理】
事件日志服务【记录每次货物的处理记录】
7.3 将ENTITY和VALUE OBJECT区别开
两者区别在于：必须被跟踪，还是仅表示一个基本值？
Customer ：一般是entity，但如何跟踪，tax id ？或者其他什么？【这里讨论的跟踪号，都是与业务有关的。】
Cargo：2 个完全相同的货箱必须分开！为每件货物分配一个跟踪ID。
Handling Event 和 Carrier Movement ：它们反应的是真实世界的事件，且不能互换，应该用Entity 建模。
每个carrier movement 通过一个来自运输调度表代码识别。
另外，handling event 可以通过 cargo id ，完成时间，类型 三个信息的组合。举例而言，同一个cargo 不能在同一时间 装货且卸货。
Location ：名称因为重复，不适合作为唯一识别号。经纬度又不太合适。还是用内部标识符吧。
Delivery History ：任意两个对象之间是不可互换的。因此它是Entity。另外，Delivery History 与Cargo 是一对一的关系，所以可以考虑它的标识来自拥有它的Cargo 。
Delivery Specification ：抽象不依赖于Cargo，两个Cargo 可以去往同一个地点，使用同一个Delivery Specification ，但它们不会共用同一个Delivery History 。它是Value Object 。
Role和其他属性 ：它没有历史或者延续性，可在不同Cargo/Customer 关联中共享它。
7.4 设计运输领域中的关联
图7-2很有意思，要细细看看。
关键点：着眼于需求，比如—
如果需要对一系列货船进行跟踪，那么Carrier Movement 遍历到Handling Event 会很重要。
但是业务中只需跟踪Cargo ，所以只需从Handling Event 遍历到Carrier Movement 。
最后又用大篇幅说明了循环依赖的问题。
7.5 Aggregate 边界
类图关系中的各个Entity 所处的Aggregate 边界。
注意：一个Aggregate边界中也会出现其他的Aggregate根。
7.6 选择Repository
图7-4 说明了Repository 对Aggregate 的支持和关系。
7.7 场景走查
7.7.1 更改Cargo 的目的地
要注意看看模型中的变更逻辑。
7.7.2 重复业务
相同Customer 重复预订。可以利用Prototype 模式。但是必须十分小心。因为Cargo是Entity ，且是Aggregate 的根。对Aggregate 边界内的每个属性或者对象都要仔细考虑。【后文就是逐个检查Aggregate 边界内的……】
7.8 对象的创建
7.8.1 Cargo的FACTORY和构造函数
7.8.2 添加Handling Event
7.9 停一下，重构：Cargo Aggregate 的另一种设计
TODO 还未完结……
