领域驱动设计(DDD)靠谱么?

简介: 好像最近几年 DDD特别的火,关于DDD 到底是银弹还是垃圾 的分析网络上还是挺多的。

好像最近几年 DDD特别的火,关于DDD 到底是银弹还是垃圾 的分析网络上还是挺多的。


最近组内一名同学迷恋上了领域驱动设计(DDD),原因是在极客上花钱学习了DDD的课程,然后一心想要在工作项目中加以实践,让理论落地 😂


微信图片_20220609112802.png


DDD分层架构


相信大部分了解DDD的开发者,持支持的观点主要认为:


DDD(Domain Driven Design,领域驱动设计)作为一种软件开发方法,它可以帮助我们设计高质量的软件模型。在正确实现的情况下,我们通过DDD完成的设计恰恰就是软件的工作方式。


业务系统设计的关键是在于如何定义系统的模型以及模型之间的关系,其中主要是领域模型的定义,当我们在模型确定之后,模型之间的关系也会随之明确。


Eric Evans在《领域驱动设计-软件核心复杂性应对之道》这本书中提出了传统的四层架构模式。


简单概要理解如下:


  • 接口层 Interface:主要负责与外部系统进行交互&通信,比如一些 dubbo服务、Restful API、RMI等,这一层主要包括 Facade、DTO还有一些Assembler;


  • 应用层 Application:这一层包含的主要组件就是 Service 服务,但是要特别注意,这一层的Service不是简单的DAO层的包装,在领域驱动设计的架构里面,Service层只是一层很“薄”的一层,它内部并不实现任何逻辑,只是负责协调和转发、委派业务动作给更下层的领域层;


  • 领域层 Domain:Domain 层是领域模型系统的核心,负责维护面向对象的领域模型,几乎全部的业务逻辑都会在这一层实现。内部主要包含Entity(实体)、ValueObject(值对象)、Domain Event(领域事件)和 Repository(仓储)等多种重要的领域组件;


  • 基础设施层 Infrastructure:它主要为 Interfaces、Application 和 Domain 三层提供支撑。所有与具体平台、框架相关的实现会在 Infrastructure 中提供,避免三层特别是 Domain 层掺杂进这些实现,从而“污染”领域模型。Infrastructure 中最常见的一类设施是对象持久化的具体实现。

微信图片_20220609112805.png


贫血模型 vs 充血模型


Q1:所谓的 “贫血模型” 到底是什么呢?


在传统的MVC分层架构下,我们将项目结构分为Controller,Service,DAO 这三个主要的层,所有的业务逻辑都在Service中体现,而我们的实体类Entity却只是充当一个与数据库做ORM映射的数据容器而已,它并没有反映出模型的业务价值。


Q2:“贫血模型”有什么坏处呢?


在我们的代码 中将会到处看到各种的setter方法和各种各样的参数校验的代码,尤其是在Service层,但是这些代码它并没有反映出它的业务价值。DDD 推荐你用充血模式写代码,也就是按 OOP 的方式去做抽象,然后把行为挂在对象上,而不是以纯过程式 的方法去写代码。


Q3:所谓的充血是什么呢?


就是对象本身有很多关联的行为,而不只是一个单纯的数据库的表的字段映射。


DDD 声称的充血模式的优势是,大部分的行为被封装到了对象内部,这样我们在阅读流程代码的时候,是一目了然的,直接能看到 step 1,step 2,step 3。但实际即使我们不用 OOP 来组织行为,一样可以把不同的业务 step 做好封装和复用。


有些公司的服务粒度拆的特别细,比如只有 5000-10000 行代码,在 DDD 里声称的充血模式的优势没有那么明显。


便于指导微服务的划分?


相信很多朋友都了解“ DDD 可以有效的指导微服务拆分”,关于这点,主要是利用 界限上下文(Bounded Context)。


限界上下文是 DDD 中用来划分不同业务边界的元素,这里业务边界的含义是「解决不同业务问题」的问题域和对应的解决方案域。你可以认为限界上下文的存在是为了解决某种类型的业务问题。


那如何划分呢?


主要是将数据与功能的抽象。例如:外卖、物业、ERP这些产品的共有数据模型,用户资源可以拆分成一个服务,很简单是不是?但这是万里长征第一步,难就难在具体编码实践中的DDD运用。


很多人对此的结论就是:DDD对服务划分有帮助,但是对人员能力要求很高。



任何软件的架构演进都是螺旋式的。

微信图片_20220609112808.png

  • 当没有足够的经验直接解决问题,或问题庞大到不足以使用经验解决时,能支撑你做出决策就只有对输入问题进行有效的分析。


  • 使用 DDD 指导微服务划分,能在一定程度上弥补经验的不足,做出有理有据的系统架构设计。


做个总结吧


领域驱动开发的关注点在于领域模型,所有的考虑都应该从领域的角度出发,重心放在业务。领域模型必须能够精准地表达业务逻辑,领域模型需要在开发过程中不断被完善,并且能够指导工程师的开发工作。


但是,现实往往并不如我们所预期的一样:


  • 国内关于DDD的最佳实践还是太少了。


除了知名的几个大厂以外很少看到有关于DDD的落地实践,最佳实践太少意味着,我们可以参考的资料就少,承担的项目失败的风险就大。


  • DDD中出现了很多新概念和术语


比如 聚合根,值对象,六边形架构,CQRS(命令和查询职责分离),事件驱动等等概念。很多人看到了这么多概念的时候,心中就开始打退堂鼓了。


如果你是在大公司一线工作了两三年的程序员,这些新概念、名词的本质内容,其实应该都很好理解。没有啥值得说的。如果是为了出去分享Show一下,你倒是可以借鉴包装一下,别让自己显得那么土,哈哈哈~

微信图片_20220609112811.png


  • 关于ROI需要进一步商榷


DDD需要我们在领域建模花费很多的时间和精力,而且还可能导致付出和收益不成正比的情况。因为在界限上下文的划分上是非常考验架构师的业务水平。如果没有将业务模型很好的识别出来,那么可能很快模型就会在迭代的过程中腐败掉了。


今天主要跟大家聊了下 DDD的主要概念和服务划分上手很简单的推崇卖点。其实要把DDD用在具体的代码中,还需要开发人员的能力很高,不仅要会八股文上的东西,还要对编码技巧有很高的要求。


最后说一句:尽信书不如无书,实践是检验真理的唯一标准!


相关文章
|
消息中间件 缓存 监控
系统稳定性建设实践总结
2020年,注定是个不平凡的一年。疫情的蔓延打乱了大家既定的原有的计划,同时也催生了一些在线业务办理能力的应用诉求,作为技术同学,需要在短时间内快速支持建设系统能力并保障其运行系统稳定性。恰逢年终月份,正好梳理总结下自己的系统稳定性建设经验和思考。
系统稳定性建设实践总结
|
8月前
|
监控 容灾 Java
系统稳定性建设三件事
本文分享了作者学习稳定性工作、构建思路、落实方案,面对问题不断反思再推进的经验总结。
系统稳定性建设三件事
|
8月前
|
关系型数据库 MySQL 数据库
从MySQL优化到脑力健康:技术人与效率的双重提升
聊到效率这个事,大家应该都挺有感触的吧。 不管是技术优化还是个人状态调整,怎么能更快、更省力地完成事情,都是我们每天要琢磨的事。
174 23
|
11月前
|
设计模式 架构师 Java
设计模式之 5 大创建型模式,万字长文深剖 ,近 30 张图解!
设计模式是写出优秀程序的保障,是让面向对象保持结构良好的秘诀,与架构能力与阅读源码的能力息息相关,本文深剖设计模式之 5 大创建型模式。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
设计模式之 5 大创建型模式,万字长文深剖 ,近 30 张图解!
|
11月前
|
网络协议 数据挖掘 5G
适用于金融和交易应用的低延迟网络:技术、架构与应用
适用于金融和交易应用的低延迟网络:技术、架构与应用
467 5
|
存储 运维 架构师
架构之道:人人都是架构师(1)
架构之道:人人都是架构师
434 8
|
Ubuntu NoSQL Linux
在Ubuntu上用Qemu模拟ARM版本的Fedora39
在Ubuntu上用Qemu模拟ARM版本的Fedora39
|
存储 安全 网络安全
浅述金融行业的双模核心
【2月更文挑战第30天】当前金融行业IT架构由双模核心(稳态+敏态)和云组成。稳态核心专注于稳定业务,敏态核心服务于敏捷需求,受益于互联网和开源技术。
|
设计模式 前端开发 Java
项目终于用上了 DDD 领域驱动,太强了!
我在公司对支付业务、结算业务、资金业务使用DDD进行领域建模的两年,得到了许多好评,也面对过不少质疑,总体来说还是能收获不少,这对团队成员理解业务起着很大作用。近半年一直在研究DDD的落地实战,如今已修得阶段性成果,迫不及待与大家分享我的落地经验。 DDD分为战略设计与战术设计。一般来说,领域建模是属于战略层的,而DDD工程落地是属于战术层的,两者是否结合使用,视实际情况而定,比如传统的MVC架构也能使用DDD进行领域建模,DDD架构最好是先做DDD领域建模。 最新上线的一个微服务——内部交易中心,我们使用了DDD架构来落地,希望看完对大家有启发。
|
存储 消息中间件 Cloud Native
饿了么EMonitor演进史
可观测性作为技术体系的核心环节之一,跟随饿了么技术的飞速发展,不断自我革新。
7946 113
饿了么EMonitor演进史