文档章节

实践DDD领域驱动设计

100斤的大胖子
 100斤的大胖子
发布于 07/05 10:35
字数 2883
阅读 4228
收藏 100

说明

领域驱动设计最近又火了。概念不断被提及,但是相信对于像笔者一样的很多开发者对于其如何应用都一头雾水。

正如《实现领域驱动设计》中作者提到的不同公司的业务能力开发能力和成熟度不一样,DDD为了解决复杂业务为生,并不适合所有的软件项目,对于很多初创公司而言,业务本身就是模糊的,只是需要做出一个MVP(最小可行性产品)来试探商业模式,采用ddd显得过“重”了一点,反而给团队成员带来额外的负担,所以团队管理者首先应该关注的是软件系统是否值得做出DDD投入

不过不管黑猫白猫,能抓到老鼠就是好猫。我们以电商业务来演练和实践ddd的部分理论,并解释ddd的概念。

战略设计阶段

领域:即业务是属于哪块,电商领域,保险领域,零售领域,又可细化分为子领域。如电商下(订单交易领域、库存领域、会员领域、物流领域....)

领域专家:一般指熟悉对应领域的产品经理项目经理

子域:子域可细分为核心子域、通用子域和支撑子域,简单理解为哪部分是比较核心的就可称作核心子域,哪些功能偏边缘化叫支撑域。

互联网公司的敏捷开发模式的产品研发流程从收集需求、PRD评审、技术模块拆分这些前期流程。而战略设计即在这个阶段完成,顾名思义侧重于从宏观上对业务进行拆分,和对未来走向的预测。

DDD的目的是为了领域专家更好地与开发进行沟通合作,使得代码更好地传达业务规则。

最初的需求方可能会提一些凌乱的需求。

为了更好地传达规则,领域专家将需求整合提取出领域的概念,技术/项目管理者一起划分好子域和限界上下文。各方统一所谓的通用语言并在以后的协作中使用。比如电商业务中双方约定好中商家用户和买家用户的概念,用户和账户的概念,交易订单和支付订单、物流订单、售后订单的概念,以实现后期沟通顺畅。

最终产出:划分出了哪些子领域、上下文映射图是怎样的。

贴一个电商业务的上下文映射图(下单交易上下文为下游,其他皆为上游):

而各个上下文的交互方式,即集成限界上下文的方式其实就是我们常说的系统交互方式:RPC调用、REST接口调用、消息队列通信。

怎么理解限界上下文和子域的关系?

**限界上下文:**是一个显示边界,领域模型即存在于这个边界之内。在边界内,通用语言有特定明确的意义。

ps:是不是觉得每个字都认得,但是不知道表达了什么意思....

在理解限界上下文和子域上确实有点费劲。笔者当时的疑惑主要是:为什么要用上下文映射图而不是子域交互图,子域划分出来不就说明边界已经明确了么,为什么还专门搞一个限界上下文的概念。

关于限界上下文,贴一下个人理解:

接下来要咬文嚼字一些了。

1、从“限界”二字来说。限界上下文明确了业务范围和职责边界。针对上面问题“子域中不是已经有边界的概念了么”。可以思考一个有意思的事,子域有边界,还是说因为有了边界才有子域。听到过一个非常到位的类比:如果没有细胞壁,如何定义细胞质?

2、从“上下文”来说。上下文关注的是两个系统交互时的环境,或者说语境。

举个例子:小学是一个子域,中学是一个子域。升学这个事件动作则要上下文表达。

通用语言要在限界上下文(语境)中保证其明确意义。举个例子,商家管理上下文中,我们(平台)说的用户指的是商家而不是买家,支付上下文中,我们以支付单为核心,语境无需引入物流单、库存等词汇。

通常来说,我们可以近似地认为子域和限界上下文一一对应的。

战术设计阶段

截止到此,我们已经划分好了子域,对开发人员来说,已经拆分好了项目。各个团队可以针对自己的子域进行独立开发了。对于ddd而言,我们开始进行战术设计阶段。战略设计关心做什么,战术设计则更关心技术实现细节,即:怎么做。

先说下ddd中推荐的六边形架构

这里要吐槽一下六边形架构这个命名,搞得好像有六个什么东西一样。其实只是根据视觉形状起的名。现在叫端口与适配器架构。

转换一下是这样的

**严格分层架构:**某层只能与直接位于其下方的层发生耦合

**松散分层架构:**允许上方层可以与任意下方层发生耦合。

这里采用松散分层架构。也可按依赖倒置原则, 基础层依赖领域层的一些东西(常见的就是实体Entity)

适配器层:

负责接口转换,即是最外层请求处理类,将外部请求转化为内部API能理解的输入。对于REST接口可能是一个controller类;
对于dubbo调用来说是开放出去的provider服务类;
对于grpc调用来说,是protobuf请求对象转换处理类;
对于消息机制来说,对应的是消息的监听器

如此采用端口适配器模式,可以不影响内部服务,只需在适配器层进行增改。尽管大家不知道六边形架构的定义,但相信很多人是这样做的。无须赘述。

应用层:负责协调领域层的接口实现前端展示或返回需要。

领域层:定义领域实体和逻辑。包括实体、值对象、领域服务、领域事件、资源库。

基础层:如数据库相关。

实体和值对象

实体:  
有唯一业务标识
有自己的业务属性和行为
属性可变,有自己的生命周期

值对象: 
 可以有唯一业务标识

有自己的业务属性和行为

一旦定义不可改变

二者的关系可总结为:值对象关心对象是什么样的,实体侧重描述对象是哪个?

提到有自己的业务属性和行为这块,想想这不就是我们年轻时说的面向对象编程的思想码?

但是回顾一下会发现,这个思想好像被很多人抛诸脑后很久了,定义的对象类都成了一个个的pojo,只有属性和属性对应getter和seter方法,也就是ddd中所说的失血模型。

**失血模型:**只含属性和对应的getter/setter方法,无业务处理逻辑

贫血模型:包含不依赖持久化的部分领域逻辑,依赖持久的逻辑被放在领域服务层。

充血模型:绝大数业务逻辑都放在其中,包括持久化逻辑。少数不适合的逻辑被提取出来放在领域服务层中。

胀血模型:主张不需要领域服务层,把一些业务逻辑都放在模型对象中处理

领域服务

胀血模型主张把所有的业务逻辑放在模型中处理,但是事实上有些逻辑并不是适合放在某个领域对象中处理。比如

1、领域对象间的转换
2、某些场景下需要多个领域对象作为输入值,结果产生一个值对象。

区别于应用层的服务,领域服务处理的是业务逻辑。应用层负责对领域服务处理结果进行渲染和组装返回给前端。ps: 针对查询类的操作,建议作为应用层的查询服务单独拎出来,因为查询尝尝涉及到多个维度的查询,或把多个领域对象的查询结果组装成一个返回值对象。

举个栗子:订单领域需要向商家(PC端)和买家(APP端),商家端按发货条件时间查询所有买家的订单,操作发货处理售后等流程。买家端完成下单、查询个人订单。在应用层我们抽象三个应用处理出来,公用的查询应用、商家端应用(关联商家权限控制上下文)、买家端应用(关联买家权限控制上下文)。

领域事件

领域事件即领域业务周期中一些关键行为,关键的定义是其他地方需要依赖此事件推送业务流转。如订单被支付这个事件,需要触发库存扣减、商家待结算账户余额增加等操作。关于领域事件处理方法:跨子域处理常用消息队列发布/订阅模式,同项目处理常用注册事件监听器处理。不多描述。

聚合和资源库

领域对象之间常常有依赖关系。比如主订单-子订单(商品)项,子订单依附于主订单存在,二者的关系称作聚合,主订单作为聚合根。

@Data
public class TradeOrderEntity {
//订单号
String orderNo;
// 商品详情
List<OrderItemDetailEntity> orderItemDetails;

我们通过为每一个聚合选择一个根,并通过根来控制所有对边界内的对象的访问。外部对象只能持有根的引用;由于根控制了访问,因此我们无法绕过它去修改内部元素。所以在ddd中,资源库Repository是面向聚合根操作的,可对多个dao对象的组合使用。

@Repository
public class TradeOrderRepository {

@Autowired
TradeOrderMapper tradeOrderMapper;

@Autowired
OrderItemDetailMapper orderItemDetailMapper;
}


关于其中一些思想,笔者也没有想清楚,所谓知行合一,恐怕很多方法论要真的遇到问题了才会理解其价值。先整理到这。最后针对Java后端开发同学,提供一个模块分层的框架供参考

思考

无忌,我教你的还记得多少?” “回太师傅,我只记得一大半”

“ 那,现在呢?” “已经剩下一小半了”

“那,现在呢?” “我已经把所有的全忘记了!”

“好,你可以上了…”

© 著作权归作者所有

100斤的大胖子
粉丝 3
博文 3
码字总数 4933
作品 0
成都
高级程序员
私信 提问
加载中

评论(25)

烨儿
烨儿
微服务大行其道,还在聊十几年前的领域模型.不知道有什么意思
JacCoffee
JacCoffee
恰恰最近DDD提的比较多就是因为要解决微服务 服务划分的困境问题
ahyyxx222
ahyyxx222
因为国内大部分软件都是增删改查就能交付的以开发效率和收钱或者绩效为目标去开发的,所以在国内想普及DDD?呵呵。本来该用DDD的等发现实在太复杂了改不动的时候已经回不了头了,大家就一起在祖传屎山上继续奋战吧
S
ScalaInfo123
DDD跟目前的快速开发框架是背道而驰的,前期的设计与建模周期太长了,很难能落地的
开源中国首席罗纳尔多
开源中国首席罗纳尔多
什么叫领域驱动设计,一直没搞懂?
s
shifeng1983
不把简单的东西弄复杂了怎么忽悠人,什么web2.0,o2o,大数据,人工智能,工业4.0
子矜
子矜
是的 ,天天吹DDD 没见到落地的
CHONGCHEN
CHONGCHEN
我们公司的项目就是使用DDD做的架构
子矜
子矜
敢问贵公司是?
先进哥
先进哥
贵公司就是搞这种忽悠培训推广的?
CHONGCHEN
CHONGCHEN
做身份认证
不摘
不摘
美团有落地的案例
Glitter
Glitter
码字不易。。。
冰霜之卅ya
冰霜之卅ya
不知所云。
无爱可葬
无爱可葬
这篇文章我看过,开头的一段字都没改,也没说copy哪里的
100斤的大胖子
100斤的大胖子 博主
开发者头条上看的吧
无爱可葬
无爱可葬
不是,一本书,《领域驱动设计》还是《实现领域驱动设计》具体那本我忘了,这方面就看过这两本
100斤的大胖子
100斤的大胖子 博主
《实现领域驱动设计》 文中提了
无爱可葬
无爱可葬
是的,不过我看不下去书,就看个开头😂
guojerry
guojerry
其实DDD是最考验一个开发团队能力的,尤其是产品经理与架构师,国内大多数企业都只是停留在嘴上喊着阶段。
100斤的大胖子
100斤的大胖子 博主
DDD很多是换汤不换药的面向对象设计思想和七大设计原则理论
CHONGCHEN
CHONGCHEN
哪是你还未深入而已,切勿口若悬河
2017领域驱动设计中国峰会

本次峰会将于2017年12月8日至9日在北京举办,领域驱动设计中国峰会2017报名平台活动家。 领域驱动设计(DDD)和微服务架构(Microservices)是时下最炙手可热的两个技术词汇。在国内,随着微...

活动家
2017/10/11
0
0
云时代 l 领域驱动设计中国峰会2018

第二届云时代 | 领域驱动设计中国峰会,将在2018年11月29日-12月1日,于北京国际会议中心再次举办。届时我们将邀请来自欧洲和北美的领域驱动设计(DDD)的领军人物,以及国内诸多在过去一年当...

ThoughtWorks中国
2018/07/11
0
0
云时代 l 领域驱动设计中国峰会2018

第二届云时代 | 领域驱动设计中国峰会,将在2018年11月29日-12月1日,于北京国际会议中心再次举办。届时我们将邀请来自欧洲和北美的领域驱动设计(DDD)的领军人物,以及国内诸多在过去一年当...

ThoughtWorks中国
2018/07/11
5
0
[.NET领域驱动设计实战系列]专题十一:.NET 领域驱动设计实战系列总结

原文:[.NET领域驱动设计实战系列]专题十一:.NET 领域驱动设计实战系列总结 一、引用   其实在去年本人已经看过很多关于领域驱动设计的书籍了,包括Microsoft .NET企业级应用框架设计、领域...

杰克.陈
2017/12/05
0
0
TDD、BDD、ATDD、DDD 软件开发模式

四个开发模式意思: TDD:测试驱动开发(Test-Driven Development) BDD:行为驱动开发(Behavior Driven Development) ATDD:验收测试驱动开发(Acceptance Test Driven Development) DDD:...

飓风2000
07/11
0
0

没有更多内容

加载失败,请刷新页面

加载更多

Linux输入法fcitx的安装问题

Fcitx 总共要安装的包如下 fcitxfcitx-binfcitx-config-commonfcitx-config-gtk | fcitx-config-gtk2fcitx-datafcitx-frontend-allfcitx-frontend-gtk2fcitx-frontend-gtk3......

CHONGCHEN
41分钟前
3
0
网络基础

前言: 最近整理一些以前的学习笔记(有部分缺失,会有些乱,日后再补)。 过去都是存储在本地,此次传到网络留待备用。 计算机网络的功能: 1.数据通信; 2.资源共享; 3.增加数据可靠性; 4....

迷失De挣扎
41分钟前
3
0
spring boot升级到spring cloud

1、先升级spring boot 版本到2.1.3 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> <version>2.1.3.RELEAS......

moon888
45分钟前
10
0
从蓝鲸视角谈DevOps

DevOps源于Development和Operations的组合 常见的定义 DevOps是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变...

嘉为科技
48分钟前
1
0
微服务设计 笔记

微服务设计 一、微服务架构理论 1.六边形架构 1)六边形架构(Hexagonal Architecture),又称为端口和适配器架构风格;使用适配器与外界进行交互,外界通过应用层API与内部进行交互。 2)经典...

啃不动地大坚果
56分钟前
2
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部