面向领域事件建模

        试考虑一个打算入手IPHONE X的90后白领，他计划在网上某电商平台入手，他未必对网站的建造细节感兴趣，技术的选型，实施的计划和许许多多关于工程细节的会议，对于平台建造者与运营方是很重要的活动，但对于平台买家来讲却远远没有那么重要。

        对于IPHONE X的买家关注的是花期望的价位，在期望的时间内收到货物，要保证他的购买是没有风险的。也不排除购买者完全信任这这个平台，在其付款后，在收到货物前完全不关注订单状态，这样的用户关注的是购买的最终状态。

        较为务实的买家仍是信任平台的，但也想在付款后持续关注他的订单是正确运作的。因此，审慎的买家不是给平台付款后就无人照管了，而是为购买过程设立明确的里程碑，每个里程碑对应着某一活动的完成，并且仅当里程碑在依次不断的突破后，买家才会认为他的订单在正确的处理过程中。

        接下来看一看，从买家下单到收到货物，这个过程中还会有哪些里程碑呢。这里把里程碑都命名了该工程的一个稳定状态：

        对于平台买家来讲，跟踪状态变化比跟踪活运流更为重要，这些活动流可能是平台开发人员用流程图对平台的工作流建模所做的。

        对于系统设计也一样，将发现可视化，详述，构造某些对象行为的最自然的方法是着眼于从状态到状态的控制流，而不是着眼从活动到活动的控制流。后者可以用流程来表示，对于前者，基于状态机为整个系统生命周期建模或基于DDD的领域事件为系统建模都是可行方案之一。对于状态机的应用，在UML的时代非常流行，作为高级建模技术，能够完成对象或整个系统的生命周期建模，但对于复杂系统的系统生命周期建模复杂度很高，只在特定领域中应用很普遍，像电信行业。随着DDD的兴起，业内更倾向面向领域事件建模来完成这部分工作，这方面《Event Storming》实操性很强并且可以快速落地。

        回到电商平台案例，上文已经识别出买家的关键里程碑，对于一个完整的系统应由多个角色协作完成业务价值。为多个不同的角色在不同场景下实别出关键里程碑开始，如果我们把系统所有相关角色的里程碑实别出来，并按时间顺序发布出去，结果如下图。

        特定领域中发生的一件事情称为领域事件，上图中的每个里程碑即是系统中的领域事件，从整个系统生命周期的领域事件入手本质上就是一种整体性的思考过程，要求我们用整体的观点观察周围的事物，看清事件背后的结构和各要素之间的互动关系，并主动地“建构”和“解构”系统构建的各种可能。

        以事件为线索进行反推，是可以找到触发事件的命令及命令的发出者的，命令执行成功后产生事件。在实践的过程中，经常被问到的问题是查询商品算不算命令？这里有一个权衡标准，当在超市购物时，我们也会查看货架上的商品，大部分查看后并没有对我和我的购物车产生任何变化，这种没有产生副作用的操作并不是命令，当用户看完一个商品，他做了放入购物车的决定，那么，这个决定会改变其购物车的状态及后续的付款金额，即：有副作用的用户决策，可以称之为命令。

        得到命令后，很容易分析出命令的发起方，有可能是一个人或是一个系统。部分模型如下：

        到目前为止我们带着要解决的问题做的问题层面的分析，从买家如何在电商平台上购买IPHONE X开始的，到不同角色关注的领域事件，命令与角色。是时候为问题设计解决方案了，解决方案是从上图中抽象出系统元素，并看清它们之间的互动关系，系统中的元素不要使用动词，要使用名词。用动词来表述，得到的往往不是系统的结构，更像是在描述一个故事。分析后的模型如下：

        在构建任何系统时都是为了解决特定的问题，如：构建电商系统销售所有数码产品。对于问题的处理最常用到的办法是分而治之，将问题域分解成多个子域，子域解决一个或多个小问题，上图中的系统关键元素就是小问题的解决方案，这些元素我们称之为聚合。分而治之后，需要粘合这些方案协作解决整个系统要解决的问题。这时应该跳出单因思考方式，从全局看问题，透过现象看本质，分析事物之间的关系。将子关键元素自下而上的抽象出对应的子域后的部分结果是：

        对于复杂的子域，有一些相似的问题与模型，为了保证模型的整洁度，让设计元素职责单一并有效的分离模型的关注点，限定解决问题的边界可以帮助我们解决这个问题。例如：对于商品目录边界内商品的关注的属性与物流边界内商品关注的属性是不一样，把它们建模成一个商品对象，会增加模型的耦合度，语义上也会存在二义性，在语义边界内建模会简化与解耦对象模型，将这种边界与语义的限定称为限界上下文。

        限定语义边界内的一组对象解决了系统中的一类问题，有了限界上下文，系统模型开始从具体演进到抽象，也方便从抽象层面确定模型之间的关系，DDD中称之上下文关系映射，从限界上下文层面将不同的子问题联系起来让它们相互协作来解决问题。下图中用U(Upstrean)与D(Downstream)来表示上下游之间的关系，要注意上下游的方向，方向代表了特定的含义，如果U/D画反，很可能会陷入思考的误区。

        上图是我们面向领域事件建模的成果，如果作为微服务系统设计过程，你已经完成了服务分析，服务设计与服务拆分，一般情况每个限界上下文会被建模成一个服务，上文中提到的关键要素被建模成聚合。