来解决下前文的问题

前文所述的订单及订单的相关概念存在着歧义，我们来看下通过子域、限界上下文和上下文映射是怎么消除这些歧义的：

因为同名的业务词汇与实际业务关系不清导致的疑惑

“为什么不能在销售订单中增加一个是否投诉的字段，界面上都是显示在销售订单上的”

假设，这里所说的销售订单存在于销售子域下，那么这个订单应该解决的是销售过程中的问题。订单的生命周期以销售开始到销售终止。一般而言投诉属于售后环节，在销售订单上声明是否投诉字段，意味着销售订单的职能突破了销售子域。UI上的销售订单展示了聚合的信息，和同名的领域模型不一定保持一致。

因为同名的业务词汇与不同的业务词汇关联导致的疑惑

“我在订单付款后改变了买家信息，为什么我看订单的预定里的买家也发生了改变”

在订单上有两种买家信息，可以通过在不同的上下文中隔离来区别这两个拥有相同含义但却是不同词汇的词汇。在销售子域中建立两个上下文，分别为预定有界上下文和购买上下文，把订单领域模型拆分到这两个上下文中。在不同的上下文中，订单都有自己的买家信息，就解决了“在订单付款后改变了买家信息，为什么我看订单的预定里的买家也发生了改变”这个问题。

因为同名的业务词汇之间的关系不清楚导致的疑惑

“为什么我变更了profile上的买家地址，订单上的买家地址就跟着改变了”

订单存在于购买上下文，profile存在于身份信息上下文中，购买上下文和身份信息上下文存在映射关系，在订单创建时候从身份信息上下文复制买家地址，在订单中单独保存。这样就解决了“为什么我变更了profile上的买家地址，订单上的买家地址就跟着改变了”的问题。

引用：

1．《领域驱动设计》

2．《实现领域驱动设计》

3．当Subdomain遇见Bounded Context

4．DDD的终极大招——By Experience

5．《领域驱动设计学习：领域、子域、限界上下文》