业务中台方法论

在线业务中台方法论

对于业务中台，微服务、网关、REST API及语义化版本控制、六边形架构是侧重于技术架构的方法论，DevOps、敏捷项目管理是侧重于流程层面的方法论，领域驱动设计（DDD）是侧重于业务架构的方法论。要做好业务中台，以上方法论大概都不可或缺。

大家可以看到，除了微服务跟中台大致是同步发展的之外，其他方法论都是早前就存在的东西。正因为有这么多合适的方法论存在，中台才变得可行，无论如何在短期内要发展出这么多方法论是不现实的，因为方法论的威力不仅在于它要好，还在于它要流行。

技术架构和流程方面的方法论已经很流行，无需多说（六边形架构放在和DDD一起介绍）。值得关注的是领域驱动设计这么一个10多年前就被提出，这么多年一直不温不火的方法论，突然在中台领域似乎找到了它的最佳安身之所（也可以说中台找到了DDD这么一根救命稻草？）。这样的现象是会昙花一现，还是会长期持续，值得思考。

DDD的核心概念是通用语言和限界上下文。通用语言指的是在一个业务领域内通用（但不是在更大的领域内也完全通用的）的概念、术语等语言，限界上下文指的是相邻通用语言之间“翻译”的边界，比如前台业务的用户可能要变成后台清算的客户。

我觉得DDD的通用语言和一直以来的领域建模是比较相似的，更具创新意义的是限界上下文。在架构设计中，我们要不要构造那种拥有非常多属性，但每个使用者只使用少量属性，或者属性的名称和含义对使用者来说不贴切的对象？如果没有限界上下文的约束，可能会认为这样毕竟实现了更多的复用，是好的，但用限界上下文的理念来看，这样很可能是不好的。每个领域应该专注于自己领域的语言，领域之间要交互怎么办？加一种翻译机制，也就是限界上下文解决。

领域驱动和限界上下文的理念会自然延伸出六边形架构的设计。所谓六边形架构指的是一个程序的内部只需要处理业务逻辑，他的数据 / 请求从哪里来，数据要存储到哪里去（或者领域事件要发布），都通过各种适配器完成。因为这样的适配器可能较多，就不再像传统的三层（三明治）架构。不过如果六边形只有一个Input和一个Output适配器的话，和三层架构就还是差不多的。我想从三层架构进化到六边形架构的主要原因还是因为现在的环境已经从传统的C / S或B / S这样只有一个前端，也只有RDBMS这样的一个后端发展到前面有Web / 移动等多个端，向后也有RDBMS / NoSQL等多个端，横向也有服务化 / MQ等多个端的多端环境。我不知道哪天会不会发展出一个十面埋伏架构出来。