Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >可落地的DDD(6)-工程结构

可落地的DDD(6)-工程结构

作者头像
方丈的寺院
发布于 2022-11-08 05:21:28
发布于 2022-11-08 05:21:28
4740
举报
文章被收录于专栏:方丈的寺院方丈的寺院

背景

几年前我在可落地的DDD的(2)-为什么说MVC工程架构已经过时总结了基于DDD的微服务工程结构是怎么样的。那篇文章重点阐述了与MVC架构的区别。导致一些细节没有讲清楚,本文结合最近两年的实践,再详细阐述下。

应用拆解

请添加图片描述

为了实现一个端到端的用户请求,后端服务按照调用链一般可以分成四层

  1. 用户接口 应用作为provider,封装领域服务,提供给外部调用。处理用户命令与展示。这一层的价值在于防止领域模型的泄露。包括提供给本地其他领域调用、rpc调用、前端的http调用。
  2. 应用服务 很薄的一层,主要是面向usecase的。可以协调多个领域服务完成用户接口。
  3. 领域服务 领域服务层,即我们通常说的领域模型。领域内的属性、行为、事件、规则通过领域服务、领域事件、实体、值对象这些有序的组织起来。
  4. 基础设施 应用依赖的外部资源,包括存储、外部接口、消息等。

架构模式

应用被拆成四层,每一层有自己的作用。现在我们需要做的就是有效的组织这四层,以领域模型为中心,合理分层,高内聚、低耦合,隔离并解耦内部核心业务逻辑与外部应用和资源。业界比较常见的有以下几种。

分层架构

左边是传统的四层架构,即还是以调用顺序组织的。右边是依赖倒置的。

所谓依赖倒置即虽然按照运行时的调用关系是A依赖B,但是我在编译环节是让B依赖A。即A提供接口,B来实现。主要是两点

  1. 领域层不再依赖其他任何一层,这样能够实现具体的技术实现不会影响业务,不用纠结到底如何持久化,如何发消息。定义接口,让基础设施层实现。这样可以让领域模型易测试,易维护。
  2. 基础层依赖其他各层,包括领域层、接口层、应用服务层。

关于基础设施层是否依赖接口层,这点个人持怀疑态度。从实践来看。基础设施层的迭代频率要低于接口层,抽象程度高于用户接口层。从依赖角度来说,让用户接口层依赖基础设施层更合适。

下图是我们常用的分层架构。

六边形架构

请添加图片描述

网络用图,如有侵权,联系删除

六边形架构通过内外两个六边形将领域层和其他部分分割成两部分。对于其他部分,提出了2个概念。

  1. 端口(port) 即应用的入口和出口,是应用同外部交流的唯一通道。一般是以接口的形式存在。端口是在领域服务层。
  2. 适配器(adaptor) 与port相关联。对于入口层(用户接口层)是依赖调用。对于出口层(基础设施层)是接口实现的关系。适配器是在非领域层。

举个例子,用户取消支付,系统需要发布消息。领域层提供入口端口CancelPayService,出口端口sendCancelPayMsg 用户接口层在controller中调用CancelPayService. 基础设施层实现sendCancelPayMsg接口,发送一条消息到kafka。

整洁架构

请添加图片描述

网络用图,如有侵权,联系删除

整洁架构是在分层架构基础上,更清晰的定义了各层的依赖关系。按照从内到外,定义了各层的重要等级。越往里,代码越核心,依赖就应该越少。外圆依赖内圆,内圆无需感知外圆。

基础设施 -> 用户接口 -> 应用服务 -> 领域服务

菱形对称架构

请添加图片描述

网络用图,如有侵权,联系删除

菱形架构是去掉了用户接口层和基础设施层这个概念,改成叫网关,同时通过南北网关来区分。

只是换了个说法,本质上没什么区别。

总结

分层、六边形、整洁、菱形架构本质上没什么区别,都是分层。通过不同的维度来把各层关系的依赖关系阐述的更清晰。核心点在于

  1. 其他层依赖领域层,领域层不依赖任何外部内容
  2. 领域层通过端口与外部交互。这两点非常重要,能够帮助开发者专注在领域模型的开发上,而不是纠结与其他层的交互上。

至于其他层是否有明确的依赖关系是次要点,可以忽略。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2022-06-26,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 方丈的寺院 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
微服务的常见架构方式
在互联网产品愈发庞大复杂的情况下,系统架构往往影响着整个项目,单纯的单体架构已经不能满足系统需求了,那我们如何开展微服务架构呢?我们这里以: 整洁架构、六边形架构、DDD分层架构 三种架构进行分析
憧憬博客
2021/06/24
1.8K0
微服务的常见架构方式
DDD分层架构浅析
微服务架构模型有好多种,例如整洁架构、CQRS和六边形架构等等。每种架构模式虽然提出的时代和背景不同,但其核心理念都是为了设计出“高内聚低耦合”的架构,轻松实现架构演进。而DDD分层架构的出现,使架构边界变得越来越清晰,它在微服务架构模型中,占有非常重要的位置。
架构狂人
2023/08/16
1.7K0
DDD分层架构浅析
DDD这样落地
DDD这个主题已经写了好多篇文章了,结合最近的思考实践是时候总结一下,对于战略部分有点宏大,现在都是在微服务划分中起着重要作用,暂且总结战术部分
码农戏码
2021/05/24
1.6K1
DDD这样落地
架构模型DDD 分层架构
整洁架构又名“洋葱架构”。为什么叫它洋葱架构?看看下面这张图你就明白了。整洁架构的层就像洋葱片一样,它体现了分层的设计思想。
花落花相惜
2021/11/23
5000
互联网主流微服务架构模型对比分析
该架构最主要原则:依赖原则,它定义了各层依赖关系,越往内依赖越低,代码级别越高,能力越核心。外圈代码依赖只能指向内圈,内圈无需知道外圈任何情况。
JavaEdge
2021/02/22
1K0
互联网主流微服务架构模型对比分析
DDD之熵
《DDD之形》把当前一些流行的架构给通览了一篇,那是不是万事大吉,随便挑一个形态实践就行呢?
码农戏码
2021/03/23
5540
领域驱动实践总结(基本理论总结与分析+架构分析与代码设计V+具体应用设计分析)
领域驱动设计DDD是一种设计思想,它可以同时指导中台业务建模和微服务设计(中台本质是业务模型,微服务是业务模型的系统落地),领域驱动设计强调领域模型和微服务设计的一体性,先有领域模型然后才有微服务,而不是脱离领域模型来谈微服务设计。
全栈程序员站长
2022/08/11
1.1K1
领域驱动实践总结(基本理论总结与分析+架构分析与代码设计V+具体应用设计分析)
DDD之形
DDD现在已然变成哲学,正因为是哲学,所以法无定法,到底怎么具体怎么实施,各显神通,心法固然重要,但心法有几人能真正领悟,一说就懂,一问就不会,一讨论就吵架;所以还是从外形看看,收集一些实践后的形态,由表入里,以形学形,慢慢品
码农戏码
2021/03/23
7250
DDD领域驱动设计实战-分层架构
整洁架构、CQRS、六边形架构等微服务架构都旨在“高内聚低耦合”。那DDD分层架构又如何?
JavaEdge
2021/01/22
1.9K0
DDD领域驱动设计实战-分层架构
菱形对称架构
在实施领域驱动设计的过程中,限界上下文(Bounded Context)扮演了关键角色:它既是维护领域模型完整性与一致性的重要边界,又是系统架构的重要组成部分。随着社区对限界上下文的重视,越来越多的人开始尝试将更多的架构实践与限界上下文融合在一起,创造出符合领域驱动设计的架构模式。
张逸
2020/03/26
1.9K0
菱形对称架构
美团专家漫谈分层架构
如果系统没有分层,当业务规模增加或流量增大时我们只能针对整体系统来做扩展。分层之后可以很方便的把一些模块抽离出来,独立成一个系统。
肉眼品世界
2021/01/06
1.3K0
领域驱动设计(DDD)实践之路(一)
领域驱动设计(Domain Driven Design,DDD)其实并非新理论,大家可以看看 Eric Evans 编著的《领域驱动设计》原稿首版是2003年,距今已十余年时间。与现在的分布式、微服务相比,绝对是即将步入中年的“老家伙”了。
2020labs小助手
2020/02/24
1.4K0
领域驱动设计(DDD)理论启示
过去几年通天塔一直处于快速的业务能力建设和架构完善的阶段,以应对不断增长的业务需求和容量、高可用等技术需求,现在通天塔平台已经能满足集团主站的大部分活动、频道搭建和运营能力,主流程的新需求越来越少,个性化需求和非标准化流程的数据源和服务接入的需求越来越多,有些甚至是京东零售体系外的,同时通天塔技术和产品也在积极主动寻求变化和创新,这些因素结合在一起驱动通天塔孵化出了一个以技术为导向的项目:通天塔积木,旨在构建一个基于完全开放的前端SDK和后端数据源&服务、高度灵活和强大的积木画布、能够快速移植和部署到任何第三方IT环境的活动搭建解决方案,这套方案的初衷和设计理念也契合了京东国际化赋能和PaaS化的战略。目前通天塔积木已经取得阶段性成果,已开始赋能京东国内和国际站,但如何应对异常复杂的积木业务逻辑和不可预知的业务变化,构建业务和底层技术基础实施的完全解耦的系统,一直是我们面对的巨大挑战。也是时候从更高视角来看清问题和源头,思考一种能应对和控制业务复杂度、具备强扩展性和弹性的解决方案。纵观我们的目标,DDD这个词不知不觉映入了我的眼帘。
物流IT圈
2020/03/16
1.8K0
领域驱动设计(DDD)理论启示
DDD实战课--学习笔记
我认为,要想应用 DDD,首要任务就是要吃透 DDD 的核心设计思想,搞清楚 DDD、微服务和中台之间的关系。中台本质是业务模型,微服务是业务模型的系统落地,DDD 是一种设计思想,它可以同时指导中台业务建模和微服务设计,它们之间就是这样的一个铁三角关系。DDD 强调领域模型和微服务设计的一体性,先有领域模型然后才有微服务,而不是脱离领域模型来谈微服务设计。
郑子铭
2021/03/12
1.1K0
DDD实战课--学习笔记
(四)DDD之“架构”——没有规矩,不成方圆
一提到分层架构,大家应该都不会陌生。因为当我们开始从事软件开发这一行业的时候,接触到的企业项目基本都是采用分层架构的。它产生的时间比较早,可以说,分层架构模式被认为是所有架构的始祖。
爪哇缪斯
2023/05/10
1.1K0
(四)DDD之“架构”——没有规矩,不成方圆
DDD领域驱动的三种分层架构
来源:https://www.jianshu.com/p/a775836c7e25
JAVA日知录
2021/04/07
1.7K0
DDD领域驱动的三种分层架构
DDD领域驱动设计如何进行工程化落地
前面几篇文章中,笔者给大家阐述了DDD领域驱动设计的三大过程,重点围绕如何通过战略设计与战术设计进行DDD领域模型分析以及沉淀,但是还没有涉及到工程层面的落地。所有的这些架构理论或者设计模式到最后都是为了让我们的代码结构更加清晰,扩展性以及维护性更强。从而开发出bug少稳定性更好的应用。因此本文重点介绍如何进行DDD工程化落地。
慕枫技术笔记
2023/03/20
6690
DDD领域驱动设计如何进行工程化落地
DDD工程代码模型的几种包风格
在团队中,一直在灌输DDD的理念,最近review一些新开发的项目时,发现工程包结构每个人的理解都是不一样的,命名也是各有特色。
码农戏码
2022/11/18
1.4K1
DDD工程代码模型的几种包风格
菱形对称架构的表达力
在14年读《实现领域驱动设计》接触到六边形架构,感觉很受启发,每个限界上下文就对应一个六边形架构:
张逸
2023/03/23
7350
菱形对称架构的表达力
DDD的基础设施到底在哪里
Eric对基础设施层(Infrastructure Layer)的定义为:“为上面各层提供通用的技术能力:为应用层传递消息,为领域层提供持久化机制,为用户界面层绘制屏幕组件,等等。基础设施层还能够通过架构框架来支持4个层次间的交互模式。”
张逸
2023/03/23
1.6K0
DDD的基础设施到底在哪里
相关推荐
微服务的常见架构方式
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档