加入现在的团队做API平台已经快一年了，此前系统是巴西的一个兄弟团队开发的，还记得当初接手的时候，项目还是一个半拉子工程，存在很多的问题。当时系统被简单的拆分成了几个独立的服务，但是这几个服务的拆分规则却没有一个人能说得清楚。还记得团队接手后做的第一次Inception上，大家决定要对系统的服务进行重新拆分，可是具体怎么拆分，当时团队里没有一个对领域驱动设计和微服务拆分有经验的成员，再加之当时的系统逻辑并没有那么的复杂，因此最后大家一商量，决定先使用一个大家都认可的新技术栈对系统进行重写，然后逐步的把现有的服务进行合并，然后等时机成熟，再根据实际需要对系统的服务进行合理的拆分。同时团队将这个微服务拆分的话题作为一个技术债记录了下来。
时间一晃就来到了今年的8月份，由于系统中的某些部分跟其他兄弟团队的系统存在一定的重叠，出于服务重用的目的，我们需要将这一部分功能进行单独的封装，于是服务拆分的话题再一次被提上了日程。这一次，通过近一年的开发，我们对系统的业务领域有了较为全面的认识，同时团队的几个小伙伴业余时间也储备了一定的领域驱动设计的理论知识，于是我们组织了两轮领域驱动设计的工作坊，对现有API平台的业务进行了重新的整理和划分。
两个下午的工作坊我们按照事件风暴--命令风暴--寻找聚合--划分限界上下文的顺序进行。第一轮工作坊中，我们主要进行事件风暴和命令风暴两个环节，因为有一部分团队成员并不具备领域驱动设计的相关积累，因此这个过程花费了一些时间用来做理论知识的介绍和学习。第二轮的工作坊里，我们根据第一轮产出的事件流，识别出了系统中的聚合。最后统一了系统的子域，并在其中定义了不同的限界上下文，画出了上下文地图。
首先我们选择系统中最主要的几个业务场景，通过头脑风暴的方式，让大家将这些业务场景里面的事件写在便签上，然后一起贴在看板上。通过一轮的合并和讨论，我们得到了一个大家都认可的业务事件流程。
然后我们通过命令风暴将每个事件对应的命令以及参与者添加到了事件风暴产生出的事件流程中。得到了如下的事件流图：
通过识别事件流图中关联的领域模型，然后根据聚合的相关定义，分组讨论，识别出各个流程中的聚合。
再通过分组讲解和讨论，对聚合进行了再一次的调整和拉通，最后得出了系统中的聚合，如下图所示：
然后大家针对已经统一好的聚合，按照自己的理解划分了子域，通过集体讨论，将系统的业务子域确定了下来：
根据限界上下文的定义，在各个子域中划分限界上下文：
最后根据上下文之间的上下游关系画出了上下文地图：
通过这次的领域驱动设计工作坊，团队有了很多的收获：
首先，我们完全依靠团队内部自学，完成了这一次的领域驱动设计工作坊。这次工作坊的成功进行，给了大家很大的鼓舞，增强了团队的技术自信，它让我们相信，通过我们的努力没有解决不了的问题。
其次，我们自学的理论知识，通过这一次的工作坊得到了补充和验证，补足了之前没有注意到的一些知识点，纠正了以前一些错误的理解和认识。理论与实践相结合，让大家受益匪浅。
第三，通过头脑风暴的形式，让大家对系统的认识得到了统一，将以前仅仅存在于各自大脑中的想法可视化了出来。通过工作坊，也增加了大家对于系统业务设计的参与感，让大家感觉到系统业务设计不仅仅只是需求分析和用户体验设计的事情，同时还识别出了很多之前没有关注到的系统功能。
第四，通过识别出的子域和限界上下文，拉齐了大家对于服务拆分的认识，为后面微服务的设计扫除了障碍，可以很好的指导接下来微服务拆分的工作。
当然这一次的工作坊的进行，只是团队在领域驱动设计和微服务设计上走出的一小步。接下来团队会根据工作坊产出的内容，对系统进行设计和重构，我想到那时，团队对于领域驱动设计和微服务开发的认识肯定会更加的深刻。学以致用，在实践中学习，实在是人生一大快事。
