07.领域驱动设计:掌握整洁架构、六边形架构以及3种常见微服务架构模型的对比和分析

本文主要是介绍07.领域驱动设计:掌握整洁架构、六边形架构以及3种常见微服务架构模型的对比和分析,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

目录

1、概述

2、整洁架构

3、六边形架构

4、三种微服务架构模型的对比和分析

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

5.1 中台建设要聚焦领域模型

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

5.2.1 项目级微服务

5.2.2 企业级中台微服务

5.3 应用和资源的解耦与适配

6、总结


1、概述

DDD分层架构、整洁架构、六边形架构这三种架构模型放到一起,对比分析,看看如何利用好它

们,帮助我们设计出高内聚低耦合的中台以及微服务架构。

2、整洁架构

整洁架构又名“洋葱架构”。整洁架构的层就像洋葱片一样,它体现了分层的设计思想。

在整洁架构里,同心圆代表应用软件的不同部分,从里到外依次是领域模型、领域服务、应用服务

和最外围的容易变化的内容,比如用户界面和基础设施

整洁架构最主要的原则是依赖原则,它定义了各层的依赖关系,越往里依赖越低,代码级别越高,

越是核心能力

外圆代码依赖只能指向内圆,内圆不需要知道外圆的任何情况。

领域模型实现领域内核心业务逻辑,它封装了企业级的业务规则。领域模型的主体是实体,一个实

体可以是一个带方法的对象,也可以是一个数据结构和方法集合。

应用服务实现与用户操作相关的服务组合与编排,它包含了应用特有的业务流程规则,封装和实现

了系统所有用例。

最外层主要提供适配的能力,适配能力分为主动适配和被动适配。主动适配主要实现外部用户、网

页、批处理和自动化测试等对内层业务逻辑访问适配。被动适配主要是实现核心业务逻辑对基础资

源访问的适配,比如数据库、缓存、文件系统和消息中间件等。

红圈内的领域模型、领域服务和应用服务,一起组成软件核心业务能力

3、六边形架构

六边形架构又名“端口适配器架构”。

六边形架构的核心理念是:应用是通过端口与外部进行交互的。这也是微服务架构下API网关盛行

的主要原因吧。

也就是说,在下图的六边形架构中,红圈内的核心业务逻辑(应用程序和领域模型)与外部资源

(包括 APP、Web 应用以及数据库资源等)完全隔离,仅通过适配器进行交互它解决了业务逻

辑与用户界面的代码交错问题,很好地实现了前后端分离。六边形架构各层的依赖关系与整洁架构

一样,都是由外向内依赖。

六边形架构将系统分为内六边形和外六边形两层,这两层的职能划分如下:

红圈内的六边形,实现应用的核心业务逻辑

外六边形完成外部应用、驱动和基础资源等的交互和访问,对前端应用以API主动适配的方式提供

服务,对基础资源以依赖倒置被动适配的方式实现资源访问。

六边形架构的一个端口可能对应多个外部系统,不同的外部系统也可能会使用不同的适配器,由适

配器负责协议转换。这就使得应用程序能够以一致的方式被用户、程序、自动化测试和批处理脚本

使用。

4、三种微服务架构模型的对比和分析

这三种架构模型的设计思想正是微服务架构高内聚低耦合原则的完美体现,而它们身上闪耀的正是

领域模型为中心的设计思想。

按照这种功能的差异,我们在这三种架构中划分了应用层和领域层,来承担不同的业务逻辑。

领域层实现面向领域模型,实现领域模型的核心业务逻辑,属于原子模型,它需要保持领域模型和

业务逻辑的稳定,对外提供稳定的细粒度的领域服务,所以它处于架构的核心位置。

应用层实现面向用户操作相关的用例和流程,对外提供粗粒度的API服务

可以说,这三种架构都考虑了前端需求的变与领域模型的不变。

总体来说,不管前端如何变化,在企业没有大的变革的情况下,核心领域逻辑基本不会大变,所以

领域模型相对稳定,而用例和流程则会随着外部应用需求而随时调整。把握好这个规律,我们就知

道该如何设计应用层和领域层了。

架构模型通过分层的方式来控制需求变化从外到里对系统的影响,从外向里受需求影响逐步减小。

这样设计的好处很明显了,就是可以保证领域层的核心业务逻辑不会因为外部需求和流程的变动而

调整,对于建立前台灵活、中台稳固的架构很有帮助。

中台和微服务设计的关键:领域模型和微服务的合理分层设计

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

中台本质上是领域的子域,它可能是核心域,也可能是通用域或支撑域。通常大家认为阿里的中台

对应DDD的通用域,将通用的公共能力沉淀为中台,对外提供通用共享服务。

中台作为子域还可以继续分解为子子域,在子域分解到合适大小,通过事件风暴划分限界上下文以

后,就可以定义微服务了,微服务用来实现中台的能力。表面上看,DDD、中台、微服务这三者

之间似乎没什么关联,实际上它们的关系是非常紧密的,组合在一起可以作为一个理论体系用于你

的中台和微服务设计

5.1 中台建设要聚焦领域模型

中台需要站在全企业的高度,考虑能力的共享和复用

中台设计时,我们需要建立中台内所有限界上下文的领域模型,DDD 建模过程中会考虑架构演进

和功能的重新组合。领域模型建立的过程会对业务和应用进行清晰的逻辑和物理边界(微服务)划

分。领域模型的结果会影响到后续的系统模型、架构模型和代码模型,最终影响到微服务的拆分和

项目落地。

因此,在中台设计中我们首先要聚焦领域模型,将它放在核心位置

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

微服务设计要有分层的设计思想,让各层各司其职,建立松耦合的层间关系。

不要把与领域无关的逻辑放在领域层实现,保证领域层的纯洁和领域逻辑的稳定,避免污染领域模

型。也不要把领域模型的业务逻辑放在应用层,这样会导致应用层过于庞大,最终领域模型会失

焦。如果实在无法避免,我们可以

引入防腐层,进行新老系统的适配和转换,过渡期完成后,可以直接将防腐层代码抛弃。

有的微服务可以与前端应用集成,一起完成特定的业务,这是项目级微服务。而有的则是某个职责

单一的中台微服务,企业级的业务流程需要将多个这样的微服务组合起来才能完成,这是企业级中

台微服务两类微服务由于复杂度不一样,集成方式也会有差异。

5.2.1 项目级微服务

项目级微服务的内部,遵循分层架构模型就可以了。

领域模型的核心逻辑在领域层实现,服务的组合和编排在应用层实现,通过API网关为前台应用提

供服务,实现前后端分离。但项目级的微服务,可能会调用其它微服务。通常项目级微服务之间的

集成,发生在微服务的应用层,由应用服务调用其它微服务发布在API网关上的应用服务。

它除了可以组合和编排自己的领域服务外,还可以组合和编排外部微服务的应用服务。它只要将编

排后的服务发布到API网关供前端调用,这样前端就可以直接访问自己的微服务了。

5.2.2 企业级中台微服务

企业级的业务流程,往往是多个中台微服务一起协作完成的。

企业级中台微服务的集成不能像项目级微服务一样,在某一个微服务内完成跨微服务的服务组合和

编排。

我们可以在中台微服务之上增加一层,增加的这一层它的主要职能就是处理跨中台微服务的服务组

合和编排,以及微服务之间的协调,它还可以完成前端不同渠道应用的适配。如果再将它的业务范

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

我们借用BFF(服务于前端的后端,Backend for Frontends)这个词,暂且称它为BFF 微服务

BFF微服务与其它微服务存在较大的差异,就是它没有领域模型,因此这个微服务内也不会有领域

。BFF微服务可以承担应用层和用户接口层的主要职能,完成各个中台微服务的服务组合和编

排,可以适配不同前端和渠道的要求。

5.3 应用和资源的解耦与适配

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

正是由于它们之间的这种强依赖的关系,我们一旦更换基础资源就会对应用产生很大的影响,因此

需要为应用和资源解耦。

在微服务架构中,应用层、领域层和基础层解耦是通过仓储模式,采用依赖倒置的设计方法来实现

的。在应用设计中,我们会同步考虑和基础资源的代码适配,那么一旦基础设施资源出现变更(比

如换数据库),就可以屏蔽资源变更对业务代码的影响,切断业务逻辑对基础资源的依赖,最终降

低资源变更对应用的影响。

6、总结

DDD分层架构、整洁架构、六边形架构都是以领域模型为核心,实行分层架构,内部核心业务逻

辑与外部应用、资源隔离并解耦。请务必记好这个设计思想,今后会有大用处。

这篇关于07.领域驱动设计:掌握整洁架构、六边形架构以及3种常见微服务架构模型的对比和分析的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/661416

相关文章

mybatis的整体架构

mybatis的整体架构分为三层: 1.基础支持层 该层包括:数据源模块、事务管理模块、缓存模块、Binding模块、反射模块、类型转换模块、日志模块、资源加载模块、解析器模块 2.核心处理层 该层包括:配置解析、参数映射、SQL解析、SQL执行、结果集映射、插件 3.接口层 该层包括:SqlSession 基础支持层 该层保护mybatis的基础模块,它们为核心处理层提供了良好的支撑。

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

不懂推荐算法也能设计推荐系统

本文以商业化应用推荐为例,告诉我们不懂推荐算法的产品,也能从产品侧出发, 设计出一款不错的推荐系统。 相信很多新手产品,看到算法二字,多是懵圈的。 什么排序算法、最短路径等都是相对传统的算法(注:传统是指科班出身的产品都会接触过)。但对于推荐算法,多数产品对着网上搜到的资源,都会无从下手。特别当某些推荐算法 和 “AI”扯上关系后,更是加大了理解的难度。 但,不了解推荐算法,就无法做推荐系

百度/小米/滴滴/京东,中台架构比较

小米中台建设实践 01 小米的三大中台建设:业务+数据+技术 业务中台--从业务说起 在中台建设中,需要规范化的服务接口、一致整合化的数据、容器化的技术组件以及弹性的基础设施。并结合业务情况,判定是否真的需要中台。 小米参考了业界优秀的案例包括移动中台、数据中台、业务中台、技术中台等,再结合其业务发展历程及业务现状,整理了中台架构的核心方法论,一是企业如何共享服务,二是如何为业务提供便利。

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题,本文将一起从代码层去分析为什么没有建立索引? 开源ERP项目地址:https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置

Andrej Karpathy最新采访:认知核心模型10亿参数就够了,AI会打破教育不公的僵局

夕小瑶科技说 原创  作者 | 海野 AI圈子的红人,AI大神Andrej Karpathy,曾是OpenAI联合创始人之一,特斯拉AI总监。上一次的动态是官宣创办一家名为 Eureka Labs 的人工智能+教育公司 ,宣布将长期致力于AI原生教育。 近日,Andrej Karpathy接受了No Priors(投资博客)的采访,与硅谷知名投资人 Sara Guo 和 Elad G

Retrieval-based-Voice-Conversion-WebUI模型构建指南

一、模型介绍 Retrieval-based-Voice-Conversion-WebUI(简称 RVC)模型是一个基于 VITS(Variational Inference with adversarial learning for end-to-end Text-to-Speech)的简单易用的语音转换框架。 具有以下特点 简单易用:RVC 模型通过简单易用的网页界面,使得用户无需深入了

【区块链 + 人才服务】可信教育区块链治理系统 | FISCO BCOS应用案例

伴随着区块链技术的不断完善,其在教育信息化中的应用也在持续发展。利用区块链数据共识、不可篡改的特性, 将与教育相关的数据要素在区块链上进行存证确权,在确保数据可信的前提下,促进教育的公平、透明、开放,为教育教学质量提升赋能,实现教育数据的安全共享、高等教育体系的智慧治理。 可信教育区块链治理系统的顶层治理架构由教育部、高校、企业、学生等多方角色共同参与建设、维护,支撑教育资源共享、教学质量评估、

透彻!驯服大型语言模型(LLMs)的五种方法,及具体方法选择思路

引言 随着时间的发展,大型语言模型不再停留在演示阶段而是逐步面向生产系统的应用,随着人们期望的不断增加,目标也发生了巨大的变化。在短短的几个月的时间里,人们对大模型的认识已经从对其zero-shot能力感到惊讶,转变为考虑改进模型质量、提高模型可用性。 「大语言模型(LLMs)其实就是利用高容量的模型架构(例如Transformer)对海量的、多种多样的数据分布进行建模得到,它包含了大量的先验

图神经网络模型介绍(1)

我们将图神经网络分为基于谱域的模型和基于空域的模型,并按照发展顺序详解每个类别中的重要模型。 1.1基于谱域的图神经网络         谱域上的图卷积在图学习迈向深度学习的发展历程中起到了关键的作用。本节主要介绍三个具有代表性的谱域图神经网络:谱图卷积网络、切比雪夫网络和图卷积网络。 (1)谱图卷积网络 卷积定理:函数卷积的傅里叶变换是函数傅里叶变换的乘积,即F{f*g}