我们面对的很多问题，都可以通过方法论来解决。尤其是复杂事务都需要方法论的指导（和约束），大到一个国家的治理，小到一个企业的业务开展，都离不开方法论的指导。

企业建设中台就是一个复杂的事务，涉及到组织和技术两个维度，关于建设中台对组织的挑战，上一篇已经介绍过了，大家可以翻回去看看。既然挑战主要体现在组织和技术两方面，那么方法论也必然隐藏其中。

据了解，就中台建设而言，技术维度的方法论相对已经比较成熟了，复用了很多原有的方法论，并且应用了很多先进的技术和理念。

在线业务中台方法论

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

了解技术的朋友们肯定都知道，除了微服务跟中台大致是同步发展的之外，其他方法论都是早前就存在的东西。所以说中台不是一个完全的新事物，它只是不断演化的结果，在中台出现之前就已经有很多方法论在流行了。

关于技术架构和流程方面的方法论已经被广泛讨论且被大家熟知，我就不在这里多做赘述了。但值得一提的是，10多年前就被提出来的领域驱动设计（DDD），过去一直不温不火，在遇上了中台之后，开始再一次被广泛关注并且爆火。

那么领域驱动设计（DDD）到底说的是什么呢？

领域驱动设计，即Domain-Driven Design，简称“DDD”，是Eric Evans的提出的一套综合软件系统分析和设计的面向对象建模方法。

DDD提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化，它的革命性在于领域模型准确反映了业务语言。

DDD最大的好处是：接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD让你首先考虑的是业务语言，而不是数据。

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

个人认为，DDD的通用语言和一直以来的领域建模是比较相似的，反而是限界上下文更具创新意义。

在架构设计中，我们以往都是构造了很多那种拥有多属性，但每个人只使用部分少量属性的对象，虽然看上去属性很全，可以应对多种情况的复用。但从限定上下文的理念来看，这种做法就不是很好了。每个领域都应该专注于自己领域的语言，否则领域的边界会比较模糊，可能会涉及很多无关的东西。当领域之间需要相互交流的时候，加一套翻译机制就好了。

六边形架构

DDD的落地实现离不开六边形架构以及其他几个相关领域。所谓六边形架构指的是一个程序的内部只需要处理业务逻辑，他的数据 / 请求从哪里来，数据要存储到哪里去（或者领域事件要发布），都通过各种适配器完成。

六边形架构源于 Alistair Cockburn 的工作。它是一种用于设计软件应用程序的架构模式。使用六边形架构，我们将输入和输出置于设计的边缘。这使我们能够将应用程序的中心逻辑与外部世界隔离。由于我们的输入和输出位于边缘，我们可以在不影响核心应用的情况下切换它们的处理程序。

六边形架构旨在提高我们领域模型的可维护性。六边形架构由六边形表示，六边形的每一面都代表不同的应用层。每一层都独立于其他层，因此我们可以在不影响整个系统的情况下进行单独的更改。

让我们来看看六边形架构可能是什么样子：

应用层表示为六边形。在六边形中，我们有我们的领域实体和使用它们的用例。如我们所见，没有传出依赖项。我们所有的依赖都指向中心。六边形的内部，或域，只取决于它自己。这确保了业务逻辑与技术层分离。它还确保我们可以重用域逻辑。如果我们改变我们的堆栈，它不会对域代码产生影响。核心拥有主要的业务逻辑和业务规则。

在六边形之外，我们看到与我们的应用层交互的不同适配器（不同的业务场景）。不同的业务场景与不同的应用层进行交互，从而可以满足各种场景下的业务需求。

参考文献 1  《细品中台》 冷技术热思考 风轻扬