DDD四层架构和MVC三层架构的个人理解和学习笔记

简介: 领域驱动设计(DDD)是一种以业务为核心的设计方法,与传统MVC架构不同,DDD将业务逻辑拆分为应用层和领域层,更关注业务领域而非数据库设计。其四层架构包括:Interface(接口层)、Application(应用层)、Domain(领域层)和Infrastructure(基础层)。各层职责分明,避免跨层调用,确保业务逻辑清晰。代码实现中,通过DTO、Entity、DO等对象的转换,结合ProtoBuf协议,完成请求与响应的处理流程。为提高复用性,实际项目中可增加Common层存放公共依赖。DDD强调从业务出发设计软件,适应复杂业务场景,是微服务架构的重要设计思想。

DDD的全称为Domain-driven Design,即领域驱动设计,从名字上就可以看出这里的核心就是Domain即领域。

与MVC的区别

DDD四成架构中的要素与传统三层架构还是挺相似的:

  • 用户界面层UI(User Interface Layer)
  • 业务逻辑层BLL(Business Logic Layer)
  • 数据访问层DAL(Data Access Layer)

一个主要的变化是将业务逻辑层的服务拆分成了应用层和领域层,MVC是在三层架构的基础上设计的一种框架型架构,三层架构是一种宏观的概念,适用于任何语言,而MVC只是一种比较具体的三层架构的框架实现。

MVC三层模型是面向数据库开发,接到一个需求时先设计数据库,从数据库开始倒着往controller设计实现代码逻辑,如果一开始数据库设计不合理,后期想要改动就会很困难了。

DDD四层模型是以业务领域来划分实现具体的逻辑,就像我们的衣柜,在MVC里就是一个整体的衣柜,如果家里人员越来越多,爷爷、奶奶、大宝、二宝、三宝,那么衣柜将会越来越乱。而DDD里就会分为爸爸的衣服、妈妈的衣服、女儿的衣服,甚至每一个下面还可以再细分为女儿的T恤、女儿的裤子、女儿的配饰...DDD领域驱动设计和我们常说的面向对象编程、微服务其实很相似。

软件设计关注的应该是业务,而不是数据库!以数据库来设计软件有点本末倒置,关注数据持久化只不过是受限于物理条件限制不得已而为之,就像阿里盒马领域驱动设计实践博客中作者所说的:

假设你的机器内存无限大,永远不宕机,在这个前提下,我们是不需要持久化数据的,也就是我们可以不需要数据库,那么你将会怎么设计你的软件?

代码实现

DDD架构的四层:

  • Interface层接收请求
  • Application层编排请求需要的各个Domain服务(这一层尽量薄,尽量只做编排不放业务逻辑)
  • Domain层根据领域来实现具体的业务逻辑操作
  • Infrastructure层实现数据库操作和调用外部服务

请求过程

DDD结合ProtoBuf开发接口的实现流程

  1. Interface层将ProtoBuf协议转换成Application层的DTO
  2. Application层将DTO转换成Domain层的entity
  3. Domain层调用Infrastructure层时根据entity来构造Infrastructure层的DTO
  4. Infrastructure层实现数据库操作将DTO转成DO对象,调用外部服务时则将DTO转成ProtoBuf协议

响应过程

  1. Infrastructure层实现数据库操作将DO转成DTO对象返回,调用外部服务时则将ProtoBuf协议转成DTO返回
  2. Domain层将Infrastructure层的DTO构造成entity返回
  3. Application层将Domain层的entity构造成DTO返回
  4. Interface层再将Application层的DTO转换成ProtoBuf协议返回给调用方

实体转换

  • Assembler:属于应用层,主要作用是将一个领域对象或一组领域对象转换成一个DTO数据传输对象,或将DTO转换回领域对象
  • Converter:属于基础层,其主要作用是将领域对象转换成DO数据库对象,或将DO对象转换会领域对象

代码实现

为了方便各层公共部分复用,实际项目中建议多分出一层common层,用来存放整个项目中各层公共依赖的部份,比如公共的enums枚举定义、contants常量定义、utils工具类这些:

├─interface --接口层
│  ├─XxApiImpl.java
│  └─OoApiImpl.java
│
│
├─application --应用层
│  ├─service
│  │  ├─XxApplicationService.java
│  │  ├─OoApplicationService.java
│  │  └─impl
│  │    ├─XxApplicationServiceImpl.java
│  │    └─OoApplicationServiceImpl.java
│  └─dto
│     ├─XxDTO.java
│     └─OoDTO.java
│  
│ 
├─domain --领域层
│  ├─service
│  │  ├─repository --仓储层接口
│  │  │  ├─XxRepository.java
│  │  │  └─OoRepository.java
│  │  ├─XxDomainService.java
│  │  ├─OoDomainService.java
│  │  └─impl
│  │     ├─XxDomainServiceImpl.java
│  │     └─OoDomainServiceImpl.java
│  └─entity
│     ├─XxEntity.java
│     └─OoEntity.java
│  
│ 
├─infrastructure --基础层
│  ├─repository --仓储层
│  │  ├─model --数据库DO对象
│  │  │  ├─XxDO.java
│  │  │  └─OoDO.java
│  │  ├─mapper --持久层
│  │  │  ├─XxMapper.java
│  │  │  └─OoMapper.java
│  │  └─impl
│  │    ├─XxRepositoryImpl.java
│  │    └─OoRepositoryImpl.java
│  └─dto
│     ├─XxDTO.java
│     └─OoDTO.java
│  
│
├─common --公共层
│  ├─enums --公共枚举
│  ├─constants --公共常量
│  └─utils --公共工具类
│

不允许跨层调用,interface层只能调application层,application层只能调domain层,domain层只能调infrastructure层,公共层common则各层都可以调用。

人人都是码农:AI时代,零基础也能学会编程!
关于作者:从美工、前端开发一路成功转型Java后端的野生码农🧑‍,分享UI转前端、前端转Java、全栈开发、独立开发和程序员副业...

相关文章
|
4月前
|
自然语言处理 JavaScript Java
《鸿蒙HarmonyOS应用开发从入门到精通(第2版)》学习笔记——HarmonyOS架构介绍
HarmonyOS采用分层架构设计,从下至上分为内核层、系统服务层、框架层和应用层。内核层支持多内核设计与硬件驱动;系统服务层提供核心能力和服务;框架层支持多语言开发;应用层包括系统及第三方应用,支持跨设备调度,确保一致的用户体验。
259 81
|
5月前
|
存储 前端开发 数据可视化
在实际项目中,如何选择使用 Flux 架构或传统的 MVC 架构
在实际项目中选择使用Flux架构或传统MVC架构时,需考虑项目复杂度、团队熟悉度和性能需求。Flux适合大型、高并发应用,MVC则适用于中小型、逻辑简单的项目。
|
5月前
|
前端开发 测试技术 数据库
DDD架构中assembler和converter的区别
在 DDD 四层架构模式中,assembler 和 converter 常用于对象转换,但两者在实际项目中的使用较为随意。本文从英文释义、语义区分和模型层区分三个方面探讨了两者的区别,建议按模型层区分,即 Interface 和 Application 层使用 assembler,Infrastructure 层使用 converter,以避免混淆和随意使用。此外,将转换代码抽离为独立方法有助于保持代码整洁和可测试性。
|
6月前
|
存储 设计模式 前端开发
什么是SpringMVC?简单好理解!什么是应用分层?SpringMVC与应用分层的关系? 什么是三层架构?SpringMVC与三层架构的关系?
文章解释了SpringMVC的概念和各部分功能,探讨了应用分层的原因和具体实施的三层架构,以及SpringMVC与三层架构之间的关系和联系。
107 1
什么是SpringMVC?简单好理解!什么是应用分层?SpringMVC与应用分层的关系? 什么是三层架构?SpringMVC与三层架构的关系?
|
6月前
|
存储 前端开发 API
DDD领域驱动设计实战-分层架构
DDD分层架构通过明确各层职责及交互规则,有效降低了层间依赖。其基本原则是每层仅与下方层耦合,分为严格和松散两种形式。架构演进包括传统四层架构与改良版四层架构,后者采用依赖反转设计原则优化基础设施层位置。各层职责分明:用户接口层处理显示与请求;应用层负责服务编排与组合;领域层实现业务逻辑;基础层提供技术基础服务。通过合理设计聚合与依赖关系,DDD支持微服务架构灵活演进,提升系统适应性和可维护性。
|
8月前
|
存储 消息中间件 JSON
|
8月前
|
设计模式 存储 前端开发
MVC革命:如何用一个设计模式重塑你的应用架构,让代码重构变得戏剧性地简单!
【8月更文挑战第22天】自定义MVC(Model-View-Controller)设计模式将应用分为模型、视图和控制器三个核心组件,实现关注点分离,提升代码可维护性和扩展性。模型管理数据和业务逻辑,视图负责数据显示与用户交互,控制器处理用户输入并协调模型与视图。通过示例代码展示了基本的MVC框架实现,可根据需求扩展定制。MVC模式灵活性强,支持单元测试与多人协作,但需注意避免控制器过度复杂化。
80 1
|
8月前
|
开发者 前端开发 Java
架构模式的诗与远方:如何在MVC的田野上,用Struts 2编织Web开发的新篇章
【8月更文挑战第31天】架构模式是软件开发的核心概念,MVC(Model-View-Controller)通过清晰的分层和职责分离,成为广泛采用的模式。随着业务需求的复杂化,Struts 2框架应运而生,继承MVC优点并引入更多功能。本文探讨从MVC到Struts 2的演进,强调架构模式的重要性。MVC将应用程序分为模型、视图和控制器三部分,提高模块化和可维护性。
72 0
|
8月前
|
存储 前端开发 数据库
神秘编程世界惊现强大架构!Web2py 的 MVC 究竟隐藏着怎样的神奇魔力?带你探索实际应用之谜!
【8月更文挑战第31天】在现代 Web 开发中,MVC(Model-View-Controller)架构被广泛应用,将应用程序分为模型、视图和控制器三个部分,有助于提高代码的可维护性、可扩展性和可测试性。Web2py 是一个采用 MVC 架构的 Python Web 框架,其中模型处理数据和业务逻辑,视图负责呈现数据给用户,控制器则协调模型和视图之间的交互。
65 0
|
8月前
|
BI
软件设计与架构复杂度问题之业务简单的系统不适合使用DDD架构如何解决
软件设计与架构复杂度问题之业务简单的系统不适合使用DDD架构如何解决

热门文章

最新文章