从三种架构模型看中台和微服务设计
中台本质是领域的子域,它可能是核心域,也可能是通用域或支撑域。通常大家认为阿里的中台对应DDD的通用域,将通用的公共能力沉淀为中台,对外提供通用共享服务。
中台作为子域还可以继续分解为子子域,在子域分解到合适大小,通过事件风暴划分限界上下文以后,就可定义微服务,微服务用来实现中台能力。
中台建设要聚焦领域模型
中台需考虑能力的共享和复用。
要建立中台内所有限界上下文的领域模型,DDD建模过程中会考虑架构演进和功能的重新组合。领域模型建立的过程会对业务和应用进行清晰的逻辑和物理边界(微服务)划分。领域模型的结果会影响到后续的系统模型、架构模型和代码模型,最终影响到微服务的拆分和项目落地。
微服务要有合理的架构分层
微服务设计要有分层思想。
保证领域层的纯洁和领域逻辑的稳定,避免污染领域模型。不要把领域模型的业务逻辑放在应用层,这样会导致应用层过大,领域模型会失焦。实在无法避免,可以引入防腐层,进行新老系统的适配和转换,过渡期完成后,可直接将防腐层代码抛弃。
微服务间层次依赖
。而有的则是某个职责单一的中台微服务,企业级的业务流程需要将多个这样的微服务组合起来才能完成,这是企业级中台微服务。两类微服务由于复杂度不一样,集成方式也会有差异。
项目级微服务
可与前端应用集成,一起完成特定业务。
项目级微服务的内部遵循分层架构模型即可。领域模型的核心逻辑在领域层实现,服务的组合和编排在应用层实现,通过API网关为前台应用提供服务,实现前后端分离。但项目级微服务可能会调用其它微服务,你看在下面这张图中,比如某个项目级微服务B调用认证微服务A,完成登录和权限认证。
通常项目级微服务之间的集成,发生在微服务的应用层,由应用服务调用其它微服务发布在API网关上的应用服务。你看下图中微服务B中红色框内的应用服务B,它除了可以组合和编排自己的领域服务外,还可以组合和编排外部微服务的应用服务。它只要将编排后的服务发布到API网关供前端调用,这样前端就可以直接访问自己的微服务了。
企业级中台微服务
可在中台微服务上增加一层,位于红色边框,负责跨中台微服务的服务组合和编排,以及微服务之间的协调,还可完成前端不同渠道应用的适配。
再将它的业务范围扩大一些,可做成一个面向不同行业和渠道的服务平台。
借用BFF(服务于前端的后端,Backend for Frontends)词。BFF微服务与其它微服务存在较大的差异,就是它没有领域模型,因此这个微服务内也不会有领域层。BFF微服务可以承担应用层和用户接口层的主要职能,完成各个中台微服务的服务组合和编排,可适配不同前端和渠道的要求。
应用和资源的解耦与适配
传统以数据为中心的设计模式,应用会对数据库、缓存、文件系统等基础资源产生严重依赖。
一旦更换基础资源就会对应用产生很大的影响,因此需要为应用和资源解耦。
在微服务架构中,应用层、领域层和基础层解耦是通过仓储模式,采用依赖倒置的设计方法来实现的。在应用设计中,我们会同步考虑和基础资源的代码适配,那么一旦基础设施资源出现变更(比如换数据库),就可以屏蔽资源变更对业务代码的影响,切断业务逻辑对基础资源的依赖,最终降低资源变更对应用的影响。
总结
DDD分层架构、整洁架构、六边形架构都是以领域模型为核心,实行分层架构,内部核心业务逻辑与外部应用、资源隔离并解耦。