再议DDD分层

简介: 之前整理过《DDD分层》[1] 以及《分层架构》[2]最近看网友讨论,整理一些有亮点的地方现在分层架构+整洁架构似乎是个万金油组合了之前DDD的标准分层结构:

之前整理过《DDD分层》[1] 以及《分层架构》[2]

最近看网友讨论,整理一些有亮点的地方

现在分层架构+整洁架构似乎是个万金油组合了

之前DDD的标准分层结构:

image.png

640.gif

右边传统分层,左边经过DIP改进型,两者有什么区别呢?

image.png

眼尖的人可以看出来,两者确实差了不少

线条1:application到infrastructure被反转了

线条2:这条线没有了,在MVC里面这线是常见的,applicaton与domain没分开,但DDD中这条线是不推荐的,就算在松散分层架构中也一般不使用,除非简单的CRUD项目

线条3:也被反转了,这其实类似CQRS中的Q部分


以上来源于群友的讨论,真的是世上无难事,只怕有心人;这点区别真没留意过

image.gifimage.png

这图来源于阿里大牛殷浩之手,《阿里DDD四弹》[3]中进行过总结,DTOAssembler放在了application层,有些不太合理

在《分层架构》中thrift的TService,为了不与controller重复,所以需要一个application service,此时thrift与controller可以有相同的业务请求

也就是说controller对外有多种输入,但对应用层来说都是同一个user case,如果放在应用层内转化,是不是应该层为了同一个use case要爆露多过方法

image.png

适配层做三件事:

1.协议适配(如采用controller,通过 @RequestMapping 注解和 JSON 序列化)2.参数规则验证(如,不能为空、手机是数字并且11位、邮箱要有@之类简单验证)3.为调用下层(应用层)转化输入(assembler)

如果说分4层的话:

1.controller (assembler、转化)2.appliction3.domain4.repository(convertor、转化)

应用层是真正的业务入口,是很披的一层:

1.用来协调领域操作 这里一般看系统架构不一样会有所不同,主要再分为同步调用的方式,和步骤事件的方式。2.关注点分离的操作(如日志、通知等)

application service编排业务,domain service编排领域

image.png

References

[1] 《DDD分层》: http://www.zhuxingsheng.com/blog/ddd-layering.html

[2] 《分层架构》: http://www.zhuxingsheng.com/blog/layered-architecture.html

[3] 《阿里DDD四弹》: http://www.zhuxingsheng.com/blog/ali-ddd-four-bombs-to-read.html

目录
相关文章
|
设计模式 JSON 架构师
你真的需要防腐层吗?DDD 系统间的7种关系梳理与实践
当提到系统间交互的时候,人们都会想到大名鼎鼎的防腐层,用来防止其他系统的模型变更对本系统造成影响。但是在实践这个模式的过程中,我们常常会遇到问题。此时我们也应该考虑下其他的系统交互方式。
27714 12
你真的需要防腐层吗?DDD 系统间的7种关系梳理与实践
|
消息中间件 网络协议 前端开发
殷浩详解DDD:如何避免写流水账代码?
在日常工作中我观察到,面对老系统重构和迁移场景,有大量代码属于流水账代码,通常能看到开发在对外的API接口里直接写业务逻辑代码,或者在一个服务里大量的堆接口,导致业务逻辑实际无法收敛,接口复用性比较差。所以本文主要想系统性的解释一下如何通过DDD的重构,将原有的流水账代码改造为逻辑清晰、职责分明的模块。
殷浩详解DDD:如何避免写流水账代码?
|
微服务 测试技术 Java
阿里技术专家详解 DDD 系列- Domain Primitive
关于DDD的一系列文章,希望能继续在总结前人的基础上发扬光大DDD的思想,但是通过一套我认为合理的代码结构、框架和约束,来降低DDD的实践门槛,提升代码质量、可测试性、安全性、健壮性。
61953 17
阿里技术专家详解 DDD 系列- Domain Primitive
|
缓存 架构师 Java
架构师必备 - DDD之落地实践
今天带大家认识下DDD,一个听起来很垃圾却真的很牛X的设计思想,架构师必备!
|
SQL 缓存 Java
殷浩详解DDD系列 第三讲 - Repository模式
# 第三讲 - Repository模式 **写在前面** 这篇文章和上一篇隔了比较久,一方面是工作比较忙,另一方面是在讲Repository之前其实应该先讲Entity(实体)、Aggregate Root(聚合根)、Bounded Context(限界上下文)等概念。但在实际写的过程中,发现单纯讲Entity相关的东西会比较抽象,很难落地。所以本文被推倒重来,从Repository
37742 8
|
设计模式 存储 缓存
初探DDD
基于学习《殷浩详解DDD:领域层设计规范》后的动手实践,简单总结,以及个人理解
|
存储 前端开发 API
DDD领域驱动设计实战-分层架构
DDD分层架构通过明确各层职责及交互规则,有效降低了层间依赖。其基本原则是每层仅与下方层耦合,分为严格和松散两种形式。架构演进包括传统四层架构与改良版四层架构,后者采用依赖反转设计原则优化基础设施层位置。各层职责分明:用户接口层处理显示与请求;应用层负责服务编排与组合;领域层实现业务逻辑;基础层提供技术基础服务。通过合理设计聚合与依赖关系,DDD支持微服务架构灵活演进,提升系统适应性和可维护性。
|
Java Spring
ddd 领域事件 springboot 代码案例
ddd 领域事件 springboot 代码案例
429 0
|
存储 API 数据库
深入探索DDD与事件溯源:使用Entity Framework Core构建高效且可维护的领域驱动设计应用——从理论到实践的全方位指南,附带代码示例与最佳实践分享
【8月更文挑战第31天】本文通过实例介绍如何结合领域驱动设计(DDD)与事件溯源(Event Sourcing)及 Entity Framework Core(EF Core),构建高效且可维护的应用程序。DDD 强调业务逻辑与软件设计的紧密融合,而事件溯源则通过记录所有变更事件来重建状态。文章详细展示了创建基于 EF Core 的项目、配置数据库上下文、定义领域模型与事件,并存储和提交事件的具体步骤。通过这些技术,实现了复杂业务逻辑的持久化与重构,提高了应用程序的灵活性和扩展性。
417 0
|
前端开发 架构师 Java
领域驱动设计DDD从入门到代码实践
在本文中,作者将借鉴《实现领域驱动设计》的做法,介绍领域驱动设计的基本概念的同时,用一个虚拟的公司和一个虚拟的项目,把领域驱动设计进行落地实践。
14907 11
领域驱动设计DDD从入门到代码实践