服务化workshop所得

服务化于我来说是一个熟练舒适区的话题了已经，但是在这个前提下以学员身份参加了一次服务化workshop，仍旧有很多新的收获。

1. 愿景是尤为重要的，方向不清晰或者不合理，之后再做细化再调整都会偏离价值或者事倍功半。愿景体现了问题域，愿景的每一个元素都需要我们的不停反问：这真的是我们追求的价值吗？
   愿景做出来之后会贯穿整个服务化乃至服务运营过程的，期间可以有理由的调整。
   「承载太多」时看愿景，哪些是需要承载的有价值的？
   「遇事不决」时看愿景，愿景是决策的直接依据。
   面对产品愿景，我们期待它：
   a. 是用户真正想用的，而不是我们能做的
   b. 是我们作为投资人时会投的
   c. 用户是细化的

2. 一个聚合中，如果有很多的命令和事件，那可能是这个问题域的复杂度过高了，承载的职责过多，需要拆解，其业务一致性约束/强业务规则可能并不成立。

3. solution思路是：问题域 -> 解决方案域 -> 实现域
   如果缺失了对问题域的分析和认知，那我们可能会片面的把「如何实现已有的解决方案」当作问题去看，而缺失了本质上我们要解决的问题是什么。
   如果跳过了解决方案域，直接从问题域->实现域，可能产生的麻烦是没有合适粒度的解决方案，只有零散的应对问题的实现。

4. 事件风暴的时候，所有的输入如事件、命令都需要用业务adaptive的语言，要能体现出业务特色和愿景。而不是很容易就都写成了「电商语言」
   “我看你们愿景的时候被激动到了，但是到事件时顿时平淡失色很多”

5. OO和DDD的关系
   DDD is "OO done right"
   OO这个话题太大了，OO里面有封装有抽象，OO全称是Object Oriented。那么想问一下，什么是Object？什么是正确的合适的需要面对的对象？我们认为是领域中的对象，即DDD中的实体等要素

6. 领域事件的存在依据是业务关心
   举例，“登录button已点击”是不是领域事件？ It depends，首先这肯定是一个事件，那这个事件是不是领域事件（即这个事件的存在有价值），取决于业务上是否关心这个事件
   当这个业务是用户行为分析业务时，那“登录button已点击”可能就是一个领域事件。

7. 大型遗留系统存在的原因是这些专业系统所要解决的问题本身就很复杂，比如ERP。这些问题的复杂度是客观存在的，我们无法去消解这些复杂度，我们只能通过「分而治之」，去降低单个团队面对的复杂度。

8. 去看一个Event Storming的产出时，有三点可以注意：
   a. 是一个闭环。在当前的stormed events中，每个业务实体的生命周期需要是呈闭环的，如果存在没有闭环的业务实体，那么可能说明这个storming不完整、业务场景需要延展。
   b. 其中的概念/所用的词语，是否清晰、准确
   c. 其中的信息/所用的词语，是否有对应到愿景上