开发者社区> 超努力的写代码> 正文

微服务架构谈(4) plus:DDD 分层架构如何推动架构演进

简介: 微服务架构谈(4) plus:DDD 分层架构如何推动架构演进
+关注继续查看

DDD 分层架构的重要原则

在《实现领域驱动设计》书中提到,DDD 分层架构有一个重要的依赖原则:“每层只 能与位于其下方的层发生耦合。”


根据耦合的紧密程度可以分为两种架构模式:严格分层架构和松散分层架构。

严格分层架构是指任何层只能对位于其直接下方的层产生依赖,而松散分层架构则允 许某层与其任意下方的层发生依赖。从图 10-1 我们可以看出,优化后的 DDD 分层架构模 型就属于严格分层架构,而传统的 DDD 分层架构则属于松散分层架构。


那在设计时,我们应该选择什么样的架构模式呢?

综合我的经验,为了服务调用的可管理,我建议你采用严格分层架构,具体原因会在17.1 节详细介绍。


微服务架构的演进

业务和技术都不是一成不变的,领域模型也会随着业务发展不断变化和演进,而领域 模型的演进又会直接影响微服务的功能和边界。那如何实现领域模型和微服务的同步演进 呢?下面我们将从两方面展开详细分析。


在 DDD 的领域层主要有:领域服务、值对象、实体、聚合根和聚合等。一般来说实体 或值对象的简单变更,不会让领域模型和微服务发生太大变化,但聚合的重组或拆分却可 以。这是因为聚合业务功能内聚,能独立完成特定业务领域的业务逻辑。所以聚合重组或 拆分,势必会引起领域模型和微服务的系统功能变化。


这里我们可以以聚合作为组合和拆分的基本单元,完成领域模型和微服务架构的演进。我们可以将聚合作为一个完整单元,在不同的领域模型之间完成重组或者拆分,甚至可以 直接将一个聚合独立拆分为微服务。


下面结合图 10-3,以微服务 1 为例,讲解微服务架构的演进过程。


当你发现微服务 1 中聚合 a 的业务功能经常被高频访问,以致拖累整个微服务 1 的性 能时,可以将聚合 a 的代码整体从微服务 1 中剥离出来,独立为微服务 2。这样微服务 2 就 可轻松应对高性能需求的业务场景了。


在业务发展到一定阶段以后,你发现微服务 3 的领域模型有了变化,聚合 d 更适合放 到微服务 1 的领域模型中。这时你就可以将聚合 d 的代码整体搬迁到微服务 1 中。如果你 在微服务设计时,已经提前定义好了聚合之间的代码边界,那这个代码搬迁的过程就不会 太复杂,也不会花太多时间。


最后我们发现,在经历领域模型和微服务架构演进后,微服务 1 已经从最初包含聚合a、b、c,演进为包含聚合 b、c、d 的新微服务了,而微服务 1 中的聚合 a 也已经独立成微服务 了。



image.png


好的聚合和代码模型的边界设计,可以让你快速应对外部业务的频繁变化,轻松实现 领域模型和微服务架构的演进。

你可能还在想,怎样实现聚合代码的快速重组呢?别急,我会在第 14 章详细讲解。


微服务内服务的演进

在采用严格分层架构时,微服务内实体的方法会被领域服务组合和封装,领域服务又 会被应用服务组合和封装。在服务逐层组合和封装的过程中,你会发现这样一个有趣的现象。


我们看一下图 10-4。领域层通常只提供一些原子服务,比如领域服务 a、b、c。在服务设计时,你并不一定能预测到这些服务会被多少个上层服务组装。但随着系统功能增强和外部接入越来越多,应用服务会不断丰富。有一天你发现领域服务 b 和 c 同时多次被应用层的应用服务 A 和 B 组装和调用了,在 A 和 B 内它们的业务执行逻辑也基本一致。这时你 就可以考虑将领域服务 b 和 c 的功能合并,并将合并后的功能下沉到领域层,演进为新的领域服务(b+c)。这样既减少了领域服务的数量,又降低了上层应用服务组合和编排的复杂度。


这就是服务演进的过程。它们会随着业务和应用的发展而不断演进和沉淀。最后你会 发现你的领域模型变得越来越精炼,微服务也越来越能够适应需求的快速变化了。



image.png


三层架构如何演进到 DDD 分层架构


综合上面的讲解,相信你对 DDD 分层架构的优势有了一定了解。这里我们不妨总结一 下 DDD 分层架构最重要的两点优势。

  • 首先,由于层间松耦合,我们可以专注本层的设计和开发,而不必关心其他层,也 不必担心本层设计时会影响其他层。DDD 分层架构成功地降低了层与层之间的依赖。
  • 其次,DDD 分层架构使得程序的结构变得更加清晰,升级和维护变得更加容易。我 们在修改某层代码时,只要本层服务的接口参数不变,其他层可以不必修改。即使 本层的接口发生变化,也只影响相邻的上层,修改工作量小且范围可以控制,不会 带来意外的风险。


那么,传统企业架构应该如何转向 DDD 分层架构呢?我们不妨来看看下面的内容。


传统企业应用大多是单体架构,而单体架构大多采用三层架构。三层架构可以部分解 决程序内代码间调用复杂、代码职责不清的问题,但这种分层是逻辑概念,在物理上它仍 然是中心化的集中式架构,所以并不适合分布式微服务架构。


其实,DDD 分层架构内的基本要素和三层架构类似,只不过在 DDD 分层架构中,这 些要素被重新归类,划分到了不同的层,确定了层与层之间的交互规则和职责边界。


我们看一下图 10-5,分析一下从三层架构向 DDD 分层架构演进的主要变化。


由图 10-5 可知,在三层架构向 DDD 分层架构演进时,主要变化发生在业务逻辑层和 数据访问层。


我们先来看一下业务逻辑层的变化。DDD 分层架构对三层架构的业务逻辑层进行了更 清晰的划分,改善了三层架构核心业务逻辑混乱、代码改动相互影响大的问题。DDD 分层 架构将三层架构业务逻辑层的业务逻辑拆分到了应用层和领域层,分别以应用服务和领域服务等形式存在。应用服务实现服务的组合和编排,领域服务完成核心领域逻辑,应用服 务可以快速响应前端业务和流程的变化,而领域层则更加专注领域模型和实现领域逻辑。



image.png


我们再来看一下数据访问层的变化。这个变化主要发生在数据访问层和基础层之间。三层架构数据访问采用 DAO 方式,而 DDD 分层架构对数据库等基础资源访问时采用了 仓储设计模式,领域层可以通过仓储接口访问基础资源的实现逻辑。这样,通过依赖倒置 实现了各层对基础资源的解耦。原来三层架构的第三方工具包、驱动、Common、Utility、Config 等通用的、公共的基础资源统一放到了基础层。

另外,DDD 分层架构在用户接口层引入了 DTO 和 facade 接口,可以给前端应用提供 更灵活的数据和接口适配能力。


10.4 本章小结

DDD 分层架构是微服务设计和开发的核心框架。通过用户接口层、应用层、领域层和 基础层这些层次划分,可以明确微服务内各层的职能,划定各领域对象的边界,确定各领 域对象的依赖和协作方式。


DDD 分层架构也是微服务代码模型设计的主要参考依据。这种架构的分层,既体现了 微服务设计和架构演进的需求,又很好地融入了领域模型的概念,二者无缝结合,相信能 够给你的微服务设计带来不一样的体验。


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
【微服务从入门到精通】:(二)构建微服务到Docker镜像
如果单纯得做微服务开发,虽然也可以通过传统得脚本,或者Jinkens工具以脚本的方式进行CI/CD发布,但是相对于Docker镜像来讲,还不是最方便的,所以如果要做CI/CD,最好还是使用Docker镜像来发布。
1395 0
阿里云服务器如何登录?阿里云服务器的三种登录方法
购买阿里云ECS云服务器后如何登录?场景不同,阿里云优惠总结大概有三种登录方式: 登录到ECS云服务器控制台 在ECS云服务器控制台用户可以更改密码、更换系.
29172 0
元数据驱动的微服务架构(上)
传统的模型方式的核心目标是能够自动生成代码,故定义过于复杂。而微服务间的“语言”的目标与传统不同,用元数据作为“语言”驱动整个微服务架构是不错的选择。本文为普元软件产品部副总兼大数据产品线总经理王轩在云计算架构设计群的微课堂分享。
6880 0
斗胆推荐一款刚出的微服务网关
前言 使用 API 网关作为内部服务面向客户端的单一入口,是一种普遍采用的架构模式。企业组织通过良好定义的 API 将内部系统向内部和外部用户公开,通常都会采用 API 网关来处理横向的关注点,包括访问控制、速率限制、负载均衡等等,来实现安全可控的 API 开放。
2397 0
DDD领域驱动设计实战-服务和数据在微服务各层协作的最佳实践(中)
按分层架构设计出的微服务,其内部各层服务主要功能和职责如下:Facade服务、应用服务、领域服务、基础服务
58 0
一文轻松读懂微服务、集群、分布式的概念和区别
一文轻松读懂微服务、集群、分布式的概念和区别
31 0
1940
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
JS零基础入门教程(上册)
立即下载
性能优化方法论
立即下载
手把手学习日志服务SLS,云启实验室实战指南
立即下载