|
作者：步伐员田宝宝
日期：2024年10月13日
未经允许严禁复制转载
中台本质上是范畴的子域，它可能是核心域，也可能是通用域或支持域。好比通常各人以为bat的中台对应 DDD 的通用域，将通用的公共能力沉淀为中台，对外提供通用共享服务。
中台作为子域还可以继续分解为子子域，在子域分解到合适大小，通过变乱风暴划分限界上下文以后，就可以定义微服务了，微服务用来实现中台的能力。外貌上看，DDD、中台、微服务这三者之间好像没什么关联，实际上它们的关系是非常紧密的，组合在一起可以作为一个理论体系用于中台和微服务设计，这个理论体系的核心主要包罗以下三点：
1. 中台建设要聚焦范畴模型
中台需要站在全企业的高度考虑能力的共享和复用。
中台设计时，我们需要创建中台内全部限界上下文的范畴模型，DDD 建模过程中会考虑架构演进和功能的重新组合。范畴模型创建的过程会对业务和应用进行清晰的逻辑和物理界限（微服务）划分。范畴模型的结果会影响到后续的系统模型、架构模型和代码模型，最终影响到微服务的拆分和项目落地。
因此，在中台设计中我们起首要聚焦范畴模型，将它放在核心位置。
2. 微服务要有合理的架构分层
微服务设计要有分层的设计头脑，让各层各司其职，创建松耦合的层间关系。不要把与范畴无关的逻辑放在范畴层实现，包管范畴层的纯洁和范畴逻辑的稳固，避免污染范畴模型。也不要把范畴模型的业务逻辑放在应用层，这样会导致应用层过于庞大，最终范畴模型会失焦。如果着实无法避免，可以引入防腐层，进行新老系统的适配和转换，过渡期完成后，可以直接将防腐层代码抛弃。
那微服务之间是否也有条理依赖关系呢？如何实现微服务之间的服务集成？这些也是需要谨慎考虑的，好比有的微服务可以与前端应用集成，一起完成特定的业务，这是项目级微服务。而有的则是某个职责单一的中台微服务，企业级的业务流程需要将多个这样的微服务组合起来才气完成，这是企业级中台微服务。两类微服务由于复杂度不一样，集成方式也会有差异。
项目级微服务的内部遵循分层架构模型就可以了。范畴模型的核心逻辑在范畴层实现，服务的组合和编排在应用层实现，通过 API 网关为前台应用提供服务，实现前后端分离。但项目级的微服务可能会调用其它微服务，你看在下面这张图中，好比某个项目级微服务 B 调用认证微服务 A，完成登录和权限认证。
通常项目级微服务之间的集成，发生在微服务的应用层，由应用服务调用其它微服务发布在 API 网关上的应用服务。你看下图中微服务 B 中赤色框内的应用服务 B，它除了可以组合和编排自己的范畴服务外，还可以组合和编排外部微服务的应用服务。它只要将编排后的服务发布到 API 网关供前端调用，这样前端就可以直接访问自己的微服务了。
企业级微服务的业务流程往往是多个中台微服务一起协作完成的，企业级中台微服务的集成不能像项目级微服务一样，在某一个微服务内完成跨微服务的服务组合和编排。
我们可以在中台微服务之上增加一层，你看下面这张图，增加的这一层就位于赤色框内，它的主要职能就是处理跨中台微服务的服务组合和编排，以及微服务之间的协调，它还可以完成前端不同渠道应用的适配，如果再将它的业务范围扩大一些，可以将它做成一个面向不偕行业和渠道的服务平台。
可以借用 BFF（服务于前端的后端，Backend for Frontends）这个词，暂且称它为 BFF 微服务。BFF 微服务与其它微服务存在较大的差异，就是它没有范畴模型，因此这个微服务内也不会有范畴层。BFF 微服务可以承担应用层和用户接口层的主要职能，完成各个中台微服务的服务组合和编排，可以适配不同前端和渠道的要求。
3. 应用和资源的解耦与适配
传统以数据为中心的设计模式，应用会对数据库、缓存、文件系统等基础资源产生严肃依赖。
正是由于它们之间的这种强依赖的关系，所以一旦更换基础资源就会对应用产生很大的影响，因此需要为应用和资源解耦。
在微服务架构中，应用层、范畴层和基础层解耦是通过仓储模式，采用依赖倒置的设计方法来实现的。在应用设计中，一般会同步考虑和基础资源的代码适配，那么一旦基础办法资源出现变动（好比换数据库），就可以屏蔽资源变动对业务代码的影响，堵截业务逻辑对基础资源的依赖，最终低沉资源变动对应用的影响。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 | 
