DDD领域驱动设计(四)

上下文映射图

上文划分上下文之后。我们还需要进一步梳理上下文之间的关系。
梳理清楚上下文之间的关系。从内部看的话 能带来的好处：

1 任务的更好拆分，可以让单独的人去负责一块东西。
2 沟通更加顺畅。一个上下文可以明确自己对其他上下文的依赖。使得内部对接更好的对接。
3 每个团队在他的上下文中能够更加明确自己领域内的概念

限界上下文的映射关系

合作关系 两个上下文紧密合作的关系
共享内核 上下文依赖部分共享的模型
客户方供应方开发。 上下文之间有组织的上下游以来
遵奉者 上下文只能盲目依赖上下文。
防腐层 一个上下文通过一些适配和转换与另一个上下文交互
开放主机服务 定义一种协议来让其上下文来对本上下文进行访问。
发布语言 通常与开放主机服务一起使用。用来定义开放主机协议
大泥球 混杂在一起的上下文 没有边界
另谋他路。两个完全没有任何联系的上下文

回到DDD抽奖系统。抽奖核心 风控 活动准入 库存 计数五个都在抽奖领域内部。所以他们都是共生关系。也就是合作关系。

同时，抽奖上下文在进行发卷动作时，会依赖发卷服务。抽奖上下文通过防腐层对三个上下文进行隔离。而发卷通过开放主机服务作为发布语言对抽奖提供访问机制。

通过上下文映射关系 我们明确的限制了限界上下文的耦合。即在抽奖平台中。无论是上下文内部相互还是和外部上下文交互。耦合度都限定在数据耦合的层级

战术建模-----细化上下文

梳理清楚上下文之间的关系后。我们需要从战术层面上解开上下文内部的组织关系。首先看一下DDD中的定义。

实体:当一个对象由其标示而不是属性区分时。这种对象称为实体(entity).最简单的 公安系统的身份录入。对于人的模拟 即认为是entity。因为每个人都是独一无二的带身份证编号。

在实际应用中建议将属性的验证放到实体中。

值对象:当一个对象用于对事物进行描述而没有唯一标示时。他被称为值对象。
比如颜色。只要知道黑色 #000000 这样的信息就能知道渲染出来的是个什么东西

值对象很重要。在习惯了使用数据库的数据建模后，很容易将所有对象看作实体。使用值对象 可以更好的做系统设计和优化。
其具有不变性、相等性和可替代性。
在实践中，需要保证值对象创建后就不能被修改。即不允许外部再修改其属性。在不同上下文集成时，会出现模型概念的公用。如商品模型会存在于电商的各个上下文中。在订单上下文中如果你只关注下单商品的信息快照，那么将商品对象看作值对象是个好的选择。