记一次事件工作坊的经历。
当你回顾你的经历时，你正在理解和消化你的初衷。
项目上一次偶然的机会，接触到了领域驱动设计。一开始接触新的概念时，总感觉它高深莫测，不知道如何运用。后来才明白，当你想要解决问题而使用这个工具时，你就开始了对他理解的过程。
这次工作坊中其实我主要扮演的是一个领域专家和观察者的身份。工作坊的过程主要分成了三个部分，电梯演讲，事件风暴和领域模型划分。下面我将尝试通过我对这三个部分的体验感受来描述我对于领域驱动设计的理解。
电梯演讲
为了目标群体，他们的诉求或痛点，这个产品名称，是一个产品特征，它可以不可抗拒的优点，而不像其他竞品，我们的产品核心的差异化竞争力。
这是业务的第一次发散。当一个领域专家在讲一个业务愿景的时候，是非常发散的。他会开始介绍他对于业务的各种理解和畅想，以及他期望达到的一个长远目标。而电梯演讲的目的就是对一个复杂的发散业务做第一次的聚合。它的目标是把一个庞大而又模糊的业务目标，抽象成一个直观的产品目标。然后将项目成员的注意力集中在某一领域，而该领域也将成为你产品所要满足的业务核心领域。
因此，在一个复杂的业务体系中，解构出我们优先需要解决的痛点和问题，这是关键的第一步。
很多时候，业务分析师在跟客户聊了很久后，发现他依然难以迈出第一步。这背后的原因就是他没有能够很好的将客户发散的思维聚合成一个可达到的明确目标。客户的想法是非常活跃，发散和无序的，当他在描述业务时，需要的是我们快速理解和抽象思维的能力，从而在一个自然语言的业务描述中迅速解构出的核心诉求和痛点，并以此基础出发，归纳产品的核心目标。这也就是我们常说的MVP（Minimum Viable Product）。我们的产品不能解决他的所有问题，但一定会解决他现实业务的核心问题。而什么是业务核心，其实是一个服务商需要去帮助领域专家去判断和分析的。
这个流程的目的就是为了快速的统一大家的目标和愿景，能够在接下来的发散中很好的去限定自己的业务范围，以便将产品目标拆解成事件。
事件风暴
使⽤事件⻛风暴梳理业务流程，建⽴领域模型，划分边界。领域事件一定是能够解决业务痛点，体现产品目标和价值的事件。
当大家构建好一个统一的产品愿景和目标时，接下来就是识别实现目标过程中所发生的事件了。这时候很多人会认为，在统一的产品目标下（即使是非常直观的业务描述），项目成员会天然的以统一的业务概念去理解产品目标所包含的事件。这是一个误区。事件风暴的其中一个目的就是在产品目标的范围内，广泛的让团队成员发散的识别业务事件，然后通过和领域专家的反复确认，来确保成员对产品目标和业务事件的理解在同一个层面上。这个过程中，非常忌讳两件事：
1. 在识别事件前就对事件做了预判；2. 识别出的事件不能映射开始设定的产品目标。
第一件事造成的后果是，在成员还没分解出业务事件前，就对什么是事件做了限定和规范。这很容易让大家失去了再一次对业务概念统一语言的机会。成员对业务事件不断的拆解和发散，才能再次检验成员是否对业务概念的理解在同一层面上。
第二件事造成的后果是，在原本已经聚合的领域中，再次发散出更多的领域。这不仅推翻了电梯演讲的结果，同时也会把项目成员再次拉回到业务领域的定位上。一方面会花费太多时间识别不在产品目标内的事件，另一方面也会影响大家对产品目标的理解和领域专家的判断。事件风暴中，避免再次引入与产品目标无关的上下文，可以很好的将成员限定在一个高效，直观，清晰的愿景中，并以此愿景对事件进行有效梳理。
发散是事件风暴的开始，但绝不是事件风暴的目标。真正的目标是在有限的时间内，聚合出领域事件。那么什么是领域事件？这时候请回归到产品定位。问问自己，这个事件的发生是否解决了业务痛点，是否会催生业务价值的产生。此时，你也可以和领域专家在一个可视化（将你识别的事件写成Sticker）的基础上对业务事件再次确认，帮助你判断。有时候，如果正向询问无法判断时，不妨反问自己，这个事件不发生会有什么影响，不发生是不是就达不成产品目标？这样也能有效地识别出领域事件。
领域模型划分
通过分析前一步产品的领域事件寻找领域模型。
当我们识别出领域事件后，我们应该做什么呢？这时不妨想想你的初衷，我们为什么要做领域驱动设计？业务的变化和发展是不可预测和控制的，在原本的系统设计中，我们习惯通过业务流程和用户操作来建立实体间的联系，这种设计方式很便捷也很直观。可当业务发生变化时，当你再用之前的系统结构去解决业务问题时，你会发现你需要构建一个更复杂的实体或逻辑来实现业务变化。这时候你首先要做的，就是解耦系统架构和数据实体的依赖关系。当你成功解耦依赖，你会发现你一个复杂的业务系统可以通过领域模型的联系来解释，因此领域模型的提炼是为了实现架构设计上的解耦。
当分析清楚领域事件，命令和用户后，你可以方便的提炼领域事件中同类的事件实体，并归纳出该实体上可能发生的命令。这些命令将会指导你设计对该实体的系统操作。在这样的划分中，能够有效的识别出一个事件实体，在完成你的业务目标过程中，会通过什么样的命令，经历什么样的事件变化。这种领域模型的划分，很好的对实体对象进行了一次提炼。
聚合通过定义对象之间清晰的所属关系和边界来实现领域模型的内聚，避免错综复杂的对象关系⽹的形成，确保业务规则在领域对象的各个生命周期都得以执⾏。
经过这次工作坊的实践后，让我们再次回到领域事件的三原则：
P1: 聚焦核⼼领域（保证团队成员始终在一个统一的产品愿景下，通过识别领域事件，划分出体现业务价值的领域模型）
P2: 通过协作迭代式探索模型（每一次的发散和聚合都是通过探索，逐步将一个复杂业务系统进行归纳，抽象和解耦。这个过程并非一蹴而就，而是需要反复讨论和沟通的。同时记住没有一个系统能解决所有问题，请始终关注在现有业务的核心领域事件上）
P3: 统⼀语言（将业务概念可视化是最好的统一语言的方式。当成员不在一个语言环境下时，团队将无法进行有效的信息碰撞，导致业务事件识别的偏差。因此构建直观，清晰和统一的语言环境是划分领域模型的基础）
总的来说，这是一次良好的体验，作为一个领域专家和观察者，能看到成员在不断的试错过程中强化对于领域驱动设计概念的理解。当然，一个方法论从消化到实施需要一个漫长的过程，但正如我文中一开始说的，请首先迈出你的第一步。
网友评论