DDD工作坊心得

    做了三次工作坊，感受不尽相同。第一次做事件风暴工作坊从虚拟场景出发，觉得这东西有意思，只勉强记住了步骤。第二次从业务出发，初窥门径。第三次再做，才算跨过了门槛。但进了门才发现路还有那么远。

1、为什么事件风暴行

        《Introducing EventStorming》书中用左图对事件风暴进行了介绍。阐释了从系统外部与用户的交互，到系统内的事件传递，以及通过事件影响到读模型从而给予用户动作的响应。形成闭环，反应了系统的运转。事件风暴工作坊提供了一个还原和分析系统的方法。按步骤做完命令风暴，整理到右图这种形式，刚好与左图对应。工作坊中便利贴的颜色正是对应到左图。

  

2、业务出发

        从业务出发不是一句漂亮话。在任一阶段要做修正时，都要回到服务蓝图去验证，蓝图中到底有没有对应的业务流程，中台是否关心、要不要记录相应变化，必须以业务流程为依据。

        以前以为工作坊后面前面的步骤简单，后面的步骤难，不管是画时序图、还是设计api接口毕竟要手写代码。但现在认识到最开头梳理业务难，有了确定的蓝图，后面按部就班就可以顺利进行下去。

        另外，关于子域的划分，什么是支撑域，什么是核心域，也没有固定标准。随公司的战略、规划，在业务不同的发展阶段，因势而变，重点还是看我们在此阶段最关注什么，要培养哪些核心竞争力。

3、前后验证

        DDD不是基于文本，它提供了一种模型化的方法，可视化后有助于对齐差异、澄清问题。前后流程相互可验证、可对齐。

        服务蓝图——事件——动态模型，环环相扣，每个地方要修正都要去溯源。

4、问题

        另外，在已有系统和规划的需求两个视角反复跳跃是一个问题点。