DDD、EventStorming与业务中台

我之前的文章曾提到过业务中台与微服务的关系，而当时我的观点很简单，就是：没有直接关系。

业务中台解决的是企业级能力复用的问题，而微服务解决的是运行时解耦的问题。业务中台不一定是微服务的，采用微服务架构的也不一定就是业务中台，这些之前都提到过，这里就不赘述了。

所以很多人以为使用DDD和EventStorming规划业务中台，是因为微服务，在我看来，基于以上的分析这也是站不住脚的，难道我不用微服务架构来实现业务中台，就无法使用DDD和EventStorming了么？

DDD和EventStorming的结合，形成的是一套“领域分析方法”，可以想象成一套双剑合璧的剑阵。其目的是透过现象看本质，透过表面的业务流程来分析背后的核心领域问题和概念，而微服务架构只是使用了这套能力，来指导和帮助进行服务划分而已，并且也不是唯一的指导原则，其他还需要考虑像团队组成、变更频率、技术异构边界、SLA要求等等因素……

而对于业务中台，这套领域分析方法，则可以指导我们探究与分析业务中台规划过程中的一个最困难的问题，既：识别不同的业务线，到底有哪些业务是可以复用的？

因为如果只分析表面的功能和流程，我们总是会发现虽然不同的业务看似都差不多，但总是有不同的地方，很难抽取共性。

这就像我们看每个人，乍一看都长得差不多，一个脑袋一个身子，俩个胳膊俩条腿。但是仔细观察，又会发现每个人都是不一样的，细节上还是有很大的差别，长相不同，性格不同，做事方式也不一样。

而领域分析就像是给人照个B超一样或是做一个性格分析一样，透过外表和行为，分析背后的本质和机理，寻找不同背后的相同，找寻变化背后的不变。

而这种通过领域分析和抽象，找寻不同业务线背后面对的相同的问题域，并从中提取共性的业务模型、提取共性的业务功能、提取共性的业务流程、甚至是提取共性的业务模式，加工并予以复用的过程，也正是业务中台的规划与建设过程的关键所在。

这也是为什么当我们提到业务中台规划的时候，总是会涉及到DDD和EventStorming，并把他们作为核心方法的原因。

总结

最后，我们用武侠小说中的一段场景来收尾做个总结：

江湖上流传着一个人的传说：

十年前，他一身白衣飘飘，仗双剑叱咤江湖，但只用一剑，已天下无敌，从来没有人看到过他的另一把剑出鞘。

十年间，江湖上早已不见了白衣人的踪迹，人们虽然还在不断地传承着这流传下来的无名剑法，但忘已忘却了这个剑法背后的那个人。

十年后，江湖又是一场大乱，白衣人又重现江湖，虽然已没有几个人认识他，但是认识的人看到他之后都无不大吃一惊。

这十年，他的容貌没有一点变化。

但让人吃惊的不是他的容貌，而是他的剑：此时，双剑都已出鞘！

而他的身旁，还站着另一个持剑的少年，一样的白衣飘飘，一样的冷峻与潇洒，让人们不禁想起了白衣人十年前的样子。

两个人，三把剑，一套剑阵，能否能平息这场江湖大乱？

或是否还会有其他的英雄会横空出世？

棋至中盘，一切都还未成定论，让我们一起拭目以待！

本文转载自健荐公众号。

原文链接:https://mp.weixin.qq.com/s/H_KiY9sxTMAN4xrYwZOqRg

创作场景

白话中台番外篇：DDD、EventStorming 与业务中台（三）