Lottery抽奖项目第二章第二节：搭建DDD四层结构

已于 2023-08-28 16:34:57 修改
阅读量381 收藏 3
点赞数 1
分类专栏： java Lottery抽奖系统 后端开发 文章标签： java maven spring boot 后端
于 2023-08-27 17:21:24 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_41119146/article/details/132525374
版权

搭建DDD四层结构

DDD：Domain Driven Design

描述：基于DDD架构构建，初始化搭建工程结构

本节是陆续搭建系统和编码的开始，我们会优先完成一个基础工程的创建。一般在互联网企业这部分工作可能不需要反复处理，只需要在承接产品需要后使用脚手架或者直接复制以往工程就可以创建现有需要使用的工程了。例如 Spring 官网也提供了创建工程的脚手架，https://start.spring.io Spring Initializr 本质上也是一个 Web 应用，它可以通过 Web 界面、Spring Tool Suite、IntelliJ IDEA 等方式，构建出一个基本的 Spring Boot 项目结构。但是，我们创建的项目结构并不是一个简单的 MVC 结构，而是需要基于 DDD 四层架构进行模块化拆分，并把分布式组件 RPC 结合进行，所以这里我们需要进行框架搭建。

DDD分层架构介绍

DDD（Domain-Driven Design 领域驱动设计）是由Eric Evans最先提出，目的是对软件所涉及到的领域进行建模，以应对系统规模过大时引起的软件复杂性的问题。整个过程大概是这样的，开发团队和领域专家一起通过 通用语言(Ubiquitous Language)去理解和消化领域知识，从领域知识中提取和划分为一个一个的子领域（核心子域，通用子域，支撑子域），并在子领域上建立模型，再重复以上步骤，这样周而复始，构建出一套符合当前领域的模型。

请添加图片描述

依靠领域驱动设计的设计思想，通过事件风暴建立领域模型，合理划分领域逻辑和物理边界，建立领域对象及服务矩阵和服务架构图，定义符合DDD分层架构思想的代码结构模型，保证业务模型与代码模型的一致性。通过上述设计思想、方法和过程，指导团队按照DDD设计思想完成微服务设计和开发。

  • 拒绝泥球小单体（？？）、拒绝污染功能与服务、拒绝一加功能排期一个月
  • 架构出高可用极易符合互联网高速迭代的应用服务
  • 物料化、组装化、可编排的服务，提高人效

好多专业名词，上来就是看不懂的样子。

服务架构调用关系

请添加图片描述

  • 应用层{Application}：专业名词真JB多
    • 应用服务位于应用层。用来表述应用和用户行为，负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结构的拼装。
    • 应用层的服务包括服务和邻域事件相关服务。
    • 应用服务可对微服务内的领域服务以及微服务外的应用服务进行组合和编排，或者对基础层如文件、缓存等数据直接操作形成应用服务，对外提供粗粒度的服务。
    • 领域事件服务包括两类：领域事件的发布和订阅。通过事件总线和消息队列实现异步数据传输，实现微服务之间的解耦。
  • 领域层{Domain}：
    • 领域服务位于领域层，为完成领域中跨实体或值对象的操作转换而封装的服务，领域服务以与实体和值对象相同的方式参与实施过程。
    • 领域服务队同一个实体的一个或多个方法进行组合和封装（类？接口？），或对多个不同实体的操作进行组合或编排，对外暴露成领域服务。领域服务封装了核心的业务逻辑。实体自身的行为在实体类内部实现，向上封装成领域服务暴露。
    • 为隐藏领域层的业务逻辑实现，所有领域方法和服务等均须通过领域服务对外暴露。通过领域服务向外暴露？？
    • 为实现微服务内聚合之间的解耦，原则上禁止跨聚合的领域服务调用和跨聚合的数据相互关联。
  • 基础层{infrastructure}：
    • 基础服务位于基础层。为各层提供资源服务（如数据库、缓存等），实现各层的解耦，降低外部资源变化对业务逻辑的影响。
    • 基础服务主要为仓储服务，通过依赖反转的方式为各层提供基础资源服务，领域服务和应用服务调用仓储服务接口，利用仓储实现持久化数据对象或直接访问基础资源。
  • 接口层{interfaces}：
    • 接口服务位于用户接口层，用于处理用户发送的Restful请求和解析用户输入的配置文件等，并将信息传递给应用层。

问题：

  • 接口层的三个都不太明白；

  • 应用层与MQ的联系；MQ是什么？其存在的原因以及作用？MQ的各种功能是什么？

    • 这里的应用事件是指什么？？
    • 为什么应用层会有仓储服务接口的存在？？

  • 什么是领域层？

    • 为什么第二列三个都是“实体/值对象”？？各自指代有何不同？

  • 基础层DB和ES/文件是完全分开的？

    • 我印象ES应该是与DB有联系的？；

；

综上，就是对 DDD 领域驱动设计的一个基本描述，不过也不用过于神秘化DDD，我们可以把DDD四层架构和MVC三层架构架构理解为家里的格局，三居和四居，只不过DDD是在MVC的基础上可以更加明确了房间的布局，可能效果上就像你原来有个三居中没有独立的书房，现在四居了你可以有一个自己的小空间了。

那么，这里还有一点就是DDD结构它是一种充血模型结构，所有的服务实现都以领域为核心，应用层定义接口，领域层实现接口，领域层定义数据仓储，基础层实现数据仓储中关于DAO和Redis的操作，但同时几方又有互相的依赖。那么这样的结构再开发独立领域提供 http 接口时候，并不会有什么问题体现出来。但如果这个时候需要引入 RPC 框架，就会暴露问题了，因为使用 RPC 框架的时候，需要对外提供描述接口信息的 Jar 让外部调用方引入才可以通过反射调用到具体的方法提供者，那么这个时候，RPC 需要暴露出来，而 DDD 的系统结构又比较耦合，怎么进行模块化的分离就成了问题点。所以我们本章节在模块系统结构搭建的时候，也是以解决此项问题为核心进行处理的。

DDD+RPC，模块分离系统搭建

请添加图片描述

RPC究竟是个啥？

如果按照模块化拆分，那么会需要做一些处理，包括：

  1. 应用层，应用层，不再给领域层定义接口，而是自行处理对领域层接口的包装。否则领域层既引入了应用层的Jar，应用层也引入了领域层的Jar，就会出现循环依赖的问题。
  2. 基础层中的数据仓储的定义也需要从领域层剥离，否则也会出现循环依赖的问题。
  3. RPC 层定义接口描述，包括：入参Req、出参Res、DTO对象，接口信息，这些内容定义出来的Jar给接口层使用，也给外部调用方使用。

请添加图片描述

那么，这样拆分以后就可以按照模块化的结构进行创建系统结构了，每一层按照各自的职责完成各自的功能，同时又不会破坏DDD中领域充血模型的实现。

知识点
  1. 学习源码DDD结构分层（见个人补充部分）
  2. 知晓每个模块分层要完成的职责
  3. 直到为什么要把RPC层单独拆分出来

个人补充

DDD分层与传统三层的区别

更具DDD领域驱动设计原则，对应的软件架构也需要相应的调整。

常用的三层架构模型划分为表现层、业务逻辑层、数据访问层等，在DDD分层结构中既有联系又有区别。

主要有以下异同：

  • 在架构设计上，在DDD分层结构中，将传统三层结构的领域层拆解为应用层和领域层。其中Application划分为很薄的一层服务，非核心的逻辑放在此层去实现，核心的业务逻辑表现下沉到领域层去实现，凝练为更加精准的业务规则集合，通过领域对象去阐述说明。

img

  • 在建模方式上，DDD分层的建模思维方式有别于传统三层，传统三层通常是以数据库为起点进行数据库分析设计，而DDD则需要以业务领域模型为核心建模（即面向对象建模的方式），更能体现对现实世界的抽象。因此在DDD分层凸显领域层的重要作用，领域层为系统的核心，包括所有业务领域模型的抽象表达。
    • 私以为这样最好，数据库只是存储设备就类似于外存，领域层类似于内存+CPU，需要处理数据并做数据暂存，应该作为核心。表现层类似于显示器，内部封装的操作不需要完全知道。
  • 在职责划分上，基础设施层涵盖了2方面内容
    • 持久层功能，其中原三层架构的数据访问层下沉到基础设施层的持久化机制实现
    • 通用技术支持，一些公共通用技术也放到基础设施层去实现。
DDD分层讲解
四层架构图

请添加图片描述

应用层所在的位置，让人感觉多加了一层，感觉是复杂化的架构。

在该架构中，上层模块可以调用下层模块，反之不行。即

  • Interface—>Application|Domain|Infrastructure
  • Application---->Domain|Infrastructure
  • Domain---->Infrastructure
分层作用
分层英文描述
表现层User Interface用户界面层，或者表现层，负责向用户显示解释用户命令
应用层Application Layer定义软件要完成的任务，并且指挥协调领域对象进行不同的操作。该层不包含业务领域知识。
领域层Domain Layer或称为模型层，系统的核心，负责表达业务概念，业务状态信息以及业务规则。即包含了该领域（问题域）所有复杂的业务知识抽象和规则定义。该层主要精力要放在领域对象分析上，可以从实体，值对象，聚合（聚合根），邻域服务，领域事件，仓储，工厂等方面入手
基础设施层Infrastructure Layer主要有2方面内容，一是为领域模型提供持久化机制，当软件需要持久化能力时候才需要进行规划；一是对其他层提供通用的技术支持能力，如消息通信，通用工具，配置等的实现；
领域对象

根据战术设计，关注的领域对象主要包括：

类型英文描述
值对象Value无唯一标识的简单对象
实体Entity充血的领域模型，有唯一标识
聚合（聚合根）Aggravate实体的聚合，拥有聚合根，可为某一个实体
领域服务Service无法归类到某个具体领域模型的行为
领域事件Event不常用
仓储Repository持久化相关，与基础设施层关联
工厂Factory负责复杂对象创建
模块Module子模块引入，可以理解为子域划分
DDD编码实践（改进分层）

本文在对上述的传统四层的实践中，（1）根据依赖倒置原则对分层结构进行了改进，通过改变不同层的依赖关系（即将基础设施层倒置）来改进具体实现与抽象之间关系；（2）在基础设施层中增加引用适配层（防腐层）来增强防御策略，用来统一封装外部系统接口的引用。改进的分层结构如下：

请添加图片描述

依赖倒置原则（DIP）：

  • 高层模块不依赖与低层模块，两者都依赖于抽象；
  • 抽象不应该依赖于细节，细节依赖抽象
代码结构描述

eg.后端Java代码工程为例，表现层为此代码结构中表现为api层，对外暴露接口的最上层；

├─com.company.microservice
├─com.company.microservice
│    │ 
│    ├─apis   API接口层 
│    │    └─controller       控制器，对外提供（Restful）接口
│    │ 
│    ├─application           应用层
│    │    ├─model            数据传输对象模型及其装配器（含校验）
│    │    │    ├─assembler   装配器,，实现模型转换eg. apiModel<=> domainModel
│    │    │    └─dto         模型定义（含校验规则）      
│    │    ├─service          应用服务，非核心服务，跨领域的协作、复杂分页查询等
│    │    ├─task             任务定义，协调领域模型
│    │    ├─listener         事件监听定义
│    │    └─***              others
│    │ 
│    ├─domain   领域层
│    │    ├─common           模块0-公共代码抽取，限于领域层有效  
│    │    ├─module-xxx       模块1-xxx，领域划分的模块，可理解为子域划分     
│    │    ├─module-user      模块2-用户子域（领域划分的模块，可理解为子域划分）
│    │    │    ├─action      行为定义
│    │    │    │    ├─UserDomainService.java        领域服务,用户领域服务
│    │    │    │    ├─UserPermissionChecker.java    其他行为，用户权限检查器
│    │    │    │    ├─WhenUserCreatedEventPublisher.java     领域事件，当用户创建完成时的事件 
│    │    │    ├─model       领域聚合内模型 
│    │    │    │    ├─UserEntity.java                领域实体，有唯一标识的充血模型，如本身的CRUD操作在此处
│    │    │    │    ├─UserDictVObj.java              领域值对象，用户字典kv定义       
│    │    │    |    ├─UserDPO.java                   领域负载对象    
│    │    │    ├─repostiory  领域仓储接口
│    │    │    │    ├─UserRepository.java
│    │    │    ├─reference   领域适配接口
│    │    │    │    ├─UserEmailSenderFacade.java
│    │    │    └─factory     领域工厂  
│    │ 
│    ├─infrastructure  基础设施层
│    │    ├─persistence      持久化机制
│    │    │    ├─converter   持久化模型转换器
│    │    │    ├─po          持久化对象定义 
│    │    │    └─repository.impl  仓储类，持久化接口&实现，可与ORM映射框架结合
│    │    ├─general          通用技术支持，向其他层输出通用服务
│    │    │    ├─config      配置类
│    │    │    ├─toolkit     工具类  
│    │    │    ├─extension   扩展定义  
│    │    │    └─common      基础公共模块等 
│    │    ├─reference        引用层，包装外部接口用，防止穿插到Domain层腐化领域模型等
│    │    │    ├─dto         传输模型定义
│    │    │    ├─converter   传输模型转换器       
│    │    │    └─facade.impl 适配器具体实现，此处的RPC、Http等调用
│    │ 
│    └─resources  
│        ├─statics  静态资源
│        ├─template 系统页面 
│        └─application.yml   全局配置文件

其中在上述目录结构中，Domain层中为对module进行划分，实际上默认该层只有一个模块，根据微服务划分可以进行增加模块来规范代码结构。

扩展定义注解和接口声明
领域模型注入仓储类的问题
一些作者思考
项目按上述经典四层架构进行搭建，可以说是DDD结构实践吗？

关于这个问题，笔者想引入一对哲学概念，哲学有言形式与内容，现象与本质等辩证关系（当然与本文可能也没啥太大关系啦）；从这两个角度来阐述本人的观点：

  • 形式与内容：经典四层架构是一个DDD实现的形式，相当于给我们提供了一个框框来让我们自己去实现；在这个框框里面我们怎么实现是自由发挥的，但也是有约束的，这个约束体现在DDD对每一层的作用的约定，如每个层约定做了什么功能，充当什么角色等。尤其是对Domain层的约定，才是最重要的。那么我们按照哲学辩证的套话来说，形式上满足了DDD架构，但这应该是片面的，具体还要看内容，即具体实现是怎样的。
  • 现象与本质：接着上述观点，如果要看实现，就要具体分析一下现象与本质嘞。上面笔者也有提到，DDD除了四层经典架构，还有五层架构（包括其演化的多层架构）、六边形架构等也都是DDD提供的架构模型（形式），那这些都可以理解DDD架构模式的外显形式，那么又有哪些共性呢？可自行查询，本文直接给结论，即它们都有Domain层，Domain层，Domain层（重要的事情说三遍~~，该结论DDD作者译著有写到…），所以不管架构模式怎么演化，Domain是核心不能变。
    那么如上分析，我们在回到这个问题，我们是不是可以给出一个这样的答案：

形式上符合DDD架构，具体是不是DDD的架构实践，本质上还要看

  • （1）项目是否包括有Domain层；
  • （2）Domain层是否满足DDD战术篇的要求（或者可暂时简单理解为充血模型吧）
题外话：Spring与DDD
  • Spring框架中，Spring为我们提供了@Service @Repository 等注解，为我们分离行为和行为（注册为Bean）和属性（数据模型），同时通过@Autowired在合适地方进行注入行为，因为行为被注册为Spring容器中的Bean后，减少了频繁创建行为的开销，只有属性的数据模型作为数据的载体来传递数据。提供很大的便捷性。但也阻碍了我们应用DDD编码实践， Spring框架主张分离，DDD思想主张合并，我们在Spring框架中使用DDD则需要在其基础上进行一些权衡取舍，即如何将注册为Bean的行为穿插到原有的贫血模型中来构建充血模型是我们要解决的问题
  • 关于这个问题，笔者使用了Spring框架提供的获取容器内已经注册的Bean接口，直接调用接口，在有属性的领域模型中来获取行为；主要还是体现融入领域模型中的部分Service获取仓储接口来实现持久化过程。

参考链接：DDD-经典四层架构应用

为什么把RPC层单独拆分出来

RPC，Remote Procedute Cells，远程函数调用，完成远程函数的映射，并且将数据转化为字节流，使用网络进行传输；

woc？RPC可以实现不同编程语言之间的函数调用？？

RPC层对外提供接口描述信息；

听起来RPC层是和前后端分离紧密相关的层；不无关系，但其实是跟为其他项目提供服务有关。将A项目的RPC模块打包之后，通过在B项目中引入pom的方式即可复用A中的RPC服务。

GPT的回答：

在领域驱动设计（Domain-Driven Design，简称DDD）中，将RPC层（Remote Procedure Call layer）单独拆分为一个模块的目的是为了分离不同的关注点，提高系统的可扩展性和可维护性。

以下是一些原因和好处：

  1. 解耦领域逻辑和通信层：RPC层负责与其他系统或服务进行远程通信，通过将其与领域逻辑分离，可以确保领域模型的纯粹性和独立性。将通信细节从领域模型中分离出来，使得领域模型可以专注于解决业务问题，而不需要关注与外部系统的交互。
  2. 支持多种通信协议和技术：RPC层的拆分为一个独立的模块，使得可以灵活选择不同的通信协议和技术，比如RESTful API、SOAP、gRPC等。这样可以根据具体需求选择适合的通信方式，而不影响领域模型的实现。
  3. 提供可插拔性：通过将RPC层拆分为一个独立的模块，可以轻松地替换或添加其他的通信实现，而不需要修改领域模型的代码。这种可插拔性使得系统更加灵活，可以根据需要进行扩展和调整。
  4. 接口隔离和依赖管理：将RPC层作为一个独立模块，定义清晰的接口和契约，可以隔离不同模块之间的依赖，并且让各个模块之间的通信更加明确和可管理。这种接口隔离有助于降低系统的耦合度，提高系统的可维护性和可测试性。

需要注意的是，将RPC层拆分为一个独立模块并不是必须的，这取决于具体的系统需求和设计决策。有些情况下可能不需要将RPC层单独拆分，而是将其直接集成到领域模型中。设计时需要权衡不同的因素，并根据具体情况做出适当的决策。

项目学习源自小傅哥的知识星球
处于版权考虑，后续章节内容将以仅个人可见的形式发布。

番外：有关Java注解
Java注解基础知识

注解是JDK1.5版本开始引入的一个特性，用于对代码进行说明，可以对包、类、接口、字段、方法参数、局部变量等进行注解。它主要的作用有以下四方面：

· 生成文档，通过代码里标识的元数据生成javadoc文档。

· 编译检查，通过代码里标识的元数据让编译器在编译期间进行检查验证。

· 编译时动态处理，编译时通过代码里标识的元数据动态处理，例如动态生成代码。

· 运行时动态处理，运行时通过代码里标识的元数据动态处理，例如使用反射注入实例。

源代码当中为什么感觉有一些冗余的类？后期会优化吗？

宇zzZ
关注
专栏目录
smart-lottery抽奖系统基于COLA架构采用DDD领域驱动中四层架构
08-20
dubbo系统源码，所有源码均经过严格测试，可直接运行，有需要的自取。
smart-lottery 抽奖系统 项目是一款互联网面向C端人群营销活动类的抽奖系统
08-20
"smart-lottery 抽奖系统" 是一款基于互联网技术，专为C端用户设计的营销活动抽奖系统。该项目利用先进的软件开发框架和技术，旨在提供高效、稳定且用户体验良好的在线抽奖服务。通过深入理解该系统，我们可以掌握...
DDD（Domain Driver Design）（领域驱动设计）四层架构
土木转行的人才博客
03-30 172
领域层 实体与值之间的关系减少业务逻辑代码的复杂程度。 众多的实体维护了各自的逻辑，避免代码平铺简易在一个类中，导致代码后期改动比较麻烦。 总结： 业务开发主要在 领域层 DDD作为一种解决方案，落地是比较难的，目的是提高主要业务代码的可读性，众多实体维护各自的业务逻辑。 1.用户层：前端、客户端层面 2.应用层：Controller层面 尽量不要有业务代码 3.领域层：主要业务层(Ser...
Lottery 分布式抽奖（个人向记录总结）
最新发布
weixin_44040169的博客
07-13 1459
系统架构：以 DDD 领域驱动设计开发，微服务拆分的分布式系统架构 核心技术：SpringBoot、MyBatis、Dubbo、MQ、MySQL、XDB-Router、ES、ZK 项目描述：抽奖系统是营销平台的重要微服务之一，该系统围绕抽奖服务建设领域服务，包括规则引擎、抽奖策略、活动玩法、奖品发放等。
DDD四层架构定义
qq_43108153的博客
02-19 470
基础层：和外部交互的适配器，屏蔽外部特性，转化成应用内识别定义的数据类型。例：持久化token，mysql插入一条token数据即可根据表里所有字段来进行查询，kv(key-value)存储要根据其他字段查询时就需要单独建立二级索引，因此插入3条来保证完整性，但不管基础层如何实现，上层完全不感知。接口层：所有流量入口，接口定义、实现，同时还包括消息的监听，job的触发入口，主要有这些：grpc、http、mq、job。领域层：具体的业务逻辑实现，包含所有租户的能力实现。
DDD-经典四层架构应用
热门推荐
最爱下雨天
01-10 4万+
DDD-经典四层架构解读DDD分层与传统三层区别DDD分层详解四层架构图分层作用领域对象DDD编码实践代码结构描述领域模型注入仓储类的问题 DDD分层与传统三层区别 根据DDD领域驱动设计原则，对应的软件架构也需要做出相应的调整。 我们常用的三层架构模型划分为表现层，业务逻辑层，数据访问层等，在DDD分层结构中既有联系又有区别， 个人认为主要有如下异同： 在架构设计上，在DDD分层结构中将传统...
DDD领域驱动四层架构说明
靖节先生的博客
09-04 2514
DDD领域驱动设计 整体架构设计 架构概述 本架构以DDD为核心，保持了领域层的“干净”，结合MVC、CQRS、整洁架构、微服务架构等原理，推导出的可演进式架构。 架构职责清晰的同时，具备强大的灵活性、适用性及实用性。 架构的各个层级的细节介绍，参见代码中 framework 目录下package-info.java文件以及各 标记接口文件。 用户接口层（interfaces） 用户接口层主要式协议层，与交互协议及集成架构相关。 应当没有任何逻辑，是可以被轻易替换的。如dubbo框架，服务提供者既可以使用
DDD四层架构实践学习
顾阿瓜
11-24 8780
DDD四层架构实践前言关于DDD的误区DDD离我们很近对DDD的一些理解DDD的核心价值让业务和技术有相同的理解参考资料领域驱动设计介绍开发目标服务架构应用经验 前言 DDD领域驱动相信同学们最近都会有所听闻，而且很多大厂都是往这方面进行项目的重构，本文会说下本人目前所学习关于DDD的一些实践与心得。以下为网上的DDD概念与同事之前所总结，我觉得比较好所以分享一下。 关于DDD的误区 DDD是解决大型复杂项目的，我们当前业务比较简单，不适合DDD。 DDD要有一个完整的、符合DDD原则的代码结构，这可能增加
smart-lottery抽奖系统基于COLA架构采用DDD领域驱动中四层架构，涉及-smart-lottery.zip
01-29
《深入解析SMART-LOTTERY抽奖系统：基于COLA架构与DDD领域的四层架构设计》 SMART-LOTTERY抽奖系统是一款高效、稳定的抽奖应用，它巧妙地运用了COLA（Coordinated Orchestration of Layers Architecture）架构和...
Lottery:年会抽奖程序
05-24
2. **奖项数量配置**：年会抽奖通常设有多个奖项，如一等奖、二等奖、三等奖等。在程序中，你需要指定每个奖项的数量。这可以通过在JavaScript中定义一个对象来实现，例如`{一等奖: 1, 二等奖: 3, 三等奖: 5}`。 3....
DDD领域驱动-经典四层架构设计及应用详解
深圳市多克创新科技有限公司
11-16 5780
DDD (Domain-Driven Design)，即领域驱动设计是思考问题的方法论，用于对实际问题建模，它以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，然后将这些概念设计成一个领域模型。由领域模型驱动软件设计，用代码来实现该领域模型。所以，DDD 的核心是建立正确的领域模型。
JAVA设计模式中的四层架构Demo
04-03
基于JAVA的四层架构模式，即抽象层，实现层，业务逻辑层，组装层。本Demo强调的是一种设计思想，其实与经典设计模式中的策略模式有点类似。建议学习软件设计思想时不妨想想硬件的接口设计。Demo在Myeclpise7.0下使用UML建立类图结构，自动反向生成的JAVA代码。
DDD领域驱动设计：四层架构应用
因热爱而执着，因执着而成功。
09-28 676
分层架构是运用最为广泛的一种架构模式，几乎每个软件系统都需要通过分层来隔离不同的关注点，以应对不同需求的变化，并且使得这种变化可以独立进行。对于分层架构来说，层次越往上其抽象层次就越面向业务和用户，层次越往下其抽象层次就越面向技术和设备。我们常用的三层架构模型划分为表现层，业务逻辑层，数据访问层等，在DDD分层结构中既有联系又有区别，个人认为主要有如下异同：在架构设计上，在DDD分层结构中将传统三层架构的业务逻辑层拆解为应用层和领域层。
DDD的分层架构
FeiChangWuRao的博客
06-10 3564
DDD作为一种指导思想，还是有一些相对来说可以落地的东西，比如说他这个分层架构，整体分为以下四层： 实际上基于上图，我们可以把我们项目工程文件再具体一点，填写到上面的图片上 用户接口层（user interface）：用户接口层负责向用户显示信息和解释用户指令。这里的用户可能是：用户、程序、自动化测试和批处理脚本等等（其实我认为就是我们向外提供服务的那一层。）应用层（Application）：看资料一把来说这里不会有业务逻辑，一般是微服务的通道和多个领域或者服务的聚合。领域层Domain：领域层是业务逻辑核
DDD分层架构
R_TJW的博客
03-18 1811
1. 经典分层架构(四层架构) 2.工程目录结构 map ┣ api ┃ ┣ assembler ┃ ┣ controller ┃ ┃ ┣ v1 ┃ ┣ dto ┣ app ┃ ┣ service ┃ ┃ ┣ impl ┣ config ┣ domain ┃ ┣ aggregate ┃ ┣ entity ┃ ┣ factory ┃ ┣ repository ┃ ┣
DDD代码分层架构
Dowjone梦工厂
06-09 5329
DDD四层架构 1、用户接口层：负责用户显示信息和接受用户的指令，包含：用户、程序、自动化测试、批处理等 2、应用层：理论上不应该有业务规则或逻辑，主要面向用例和流程相关的操作，由于领域层之上，所以包含了多个聚合，可以协调多个聚合服务和领域对象完成服务编排和组合。负责处理业务用例的执行顺序和结果的拼装，例如：安全认证，权限校验，事务控制，发送或者订阅领域事件 3、领域层：领域层主要体现领域模型的业务能力，用来表达业务概念，业务状态和业务规则。 4、基础层：贯穿所有层，采用依赖倒置设计为其他层提供.
DDD-分层架构
liruiqiang05的博客
07-08 1153
DDD 分层架构包含用户接口层、应用层、领域层和基础层。通过这些层次划分，我们可以明确微服务各层的职能，划定各领域对象的边界，确定各领域对象的协作方式。这种架构既体现了微服务设计和架构演进的需求，又很好地融入了领域模型的概念，二者无缝结合，相信会给你的微服务设计带来不一样的感觉。
DDD领域驱动设计-经典四层架构划分 + DDD建模分析过程
lqs_user的博客
11-11 8236
DDD经典四层模型架构划分以及建模分析过程
DDD架构设计微入门(将springmvc三层改造为ddd四层架构)
跟Bug死扛到底
12-03 3431
ddd微入门学习笔记
lottery 抽奖系统 - 基于领域驱动设计的四层架构实践
09-17
抽奖系统是一种常见的应用，在设计抽奖系统时，使用基于领域驱动设计（Domain-Driven Design，DDD）的四层架构可以提供更好的架构实践。 在四层架构中，首先是用户界面层（User Interface Layer），用户界面层负责向用户展示抽奖界面，并接收用户的输入请求。用户界面层可以采用Web页面、移动应用等形式实现。通过使用领域驱动设计，用户界面层可以更加贴近用户需求，提供更好的用户体验。 接下来是应用层（Application Layer），应用层是整个抽奖系统的核心。应用层负责处理用户请求，协调各个领域对象之间的交互，并调用相应的领域服务和聚合根进行业务逻辑的处理。应用层在领域驱动设计中起到了承上启下的作用，通过定义和实现各种用例和操作，实现了系统的功能。 在领域层（Domain Layer）中，定义了抽奖系统中的核心业务逻辑。领域层包含了各种实体、值对象、聚合根等领域对象，通过这些领域对象的交互实现了系统的业务流程。在抽奖系统中，可以定义抽奖活动、参与者、奖品等领域对象，并在领域层中定义它们的行为和属性，从而满足系统的各项业务需求。 最后是基础设施层（Infrastructure Layer），基础设施层提供了抽奖系统运行所需的各种支持服务，包括数据库、缓存、消息队列等。在抽奖系统中，基础设施层可以提供参与者信息的持久化存储、抽奖结果的发送等功能。通过将基础设施逻辑与领域逻辑相分离，可以提高系统的可维护性和可扩展性。 综上所述，基于领域驱动设计的四层架构可以有效地设计和实现抽奖系统。通过将系统的核心业务逻辑与界面、应用和基础设施进行分离，可以实现系统的高内聚、低耦合，提供更好的扩展性和可维护性。同时，领域驱动设计还能够更好地满足用户需求，提供更好的用户体验。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值