从三种架构模型看中台和微服务设计

中台本质是领域的子域，它可能是核心域，也可能是通用域或支撑域。通常大家认为阿里的中台对应DDD的通用域，将通用的公共能力沉淀为中台，对外提供通用共享服务。

中台作为子域还可以继续分解为子子域，在子域分解到合适大小，通过事件风暴划分限界上下文以后，就可定义微服务，微服务用来实现中台能力。

中台建设要聚焦领域模型

中台需考虑能力的共享和复用。

要建立中台内所有限界上下文的领域模型，DDD建模过程中会考虑架构演进和功能的重新组合。领域模型建立的过程会对业务和应用进行清晰的逻辑和物理边界（微服务）划分。领域模型的结果会影响到后续的系统模型、架构模型和代码模型，最终影响到微服务的拆分和项目落地。

微服务要有合理的架构分层

微服务设计要有分层思想。

保证领域层的纯洁和领域逻辑的稳定，避免污染领域模型。不要把领域模型的业务逻辑放在应用层，这样会导致应用层过大，领域模型会失焦。实在无法避免，可以引入防腐层，进行新老系统的适配和转换，过渡期完成后，可直接将防腐层代码抛弃。

微服务间层次依赖

。而有的则是某个职责单一的中台微服务，企业级的业务流程需要将多个这样的微服务组合起来才能完成，这是企业级中台微服务。两类微服务由于复杂度不一样，集成方式也会有差异。

项目级微服务

可与前端应用集成，一起完成特定业务。

项目级微服务的内部遵循分层架构模型即可。领域模型的核心逻辑在领域层实现，服务的组合和编排在应用层实现，通过API网关为前台应用提供服务，实现前后端分离。但项目级微服务可能会调用其它微服务，你看在下面这张图中，比如某个项目级微服务B调用认证微服务A，完成登录和权限认证。

通常项目级微服务之间的集成，发生在微服务的应用层，由应用服务调用其它微服务发布在API网关上的应用服务。你看下图中微服务B中红色框内的应用服务B，它除了可以组合和编排自己的领域服务外，还可以组合和编排外部微服务的应用服务。它只要将编排后的服务发布到API网关供前端调用，这样前端就可以直接访问自己的微服务了。

企业级中台微服务

可在中台微服务上增加一层，位于红色边框，负责跨中台微服务的服务组合和编排，以及微服务之间的协调，还可完成前端不同渠道应用的适配。

再将它的业务范围扩大一些，可做成一个面向不同行业和渠道的服务平台。

借用BFF（服务于前端的后端，Backend for Frontends）词。BFF微服务与其它微服务存在较大的差异，就是它没有领域模型，因此这个微服务内也不会有领域层。BFF微服务可以承担应用层和用户接口层的主要职能，完成各个中台微服务的服务组合和编排，可适配不同前端和渠道的要求。

应用和资源的解耦与适配

传统以数据为中心的设计模式，应用会对数据库、缓存、文件系统等基础资源产生严重依赖。

一旦更换基础资源就会对应用产生很大的影响，因此需要为应用和资源解耦。

在微服务架构中，应用层、领域层和基础层解耦是通过仓储模式，采用依赖倒置的设计方法来实现的。在应用设计中，我们会同步考虑和基础资源的代码适配，那么一旦基础设施资源出现变更（比如换数据库），就可以屏蔽资源变更对业务代码的影响，切断业务逻辑对基础资源的依赖，最终降低资源变更对应用的影响。

总结

DDD分层架构、整洁架构、六边形架构都是以领域模型为核心，实行分层架构，内部核心业务逻辑与外部应用、资源隔离并解耦。