DDD 工程结构

本文深入探讨了领域驱动设计(DDD)的工程结构,包括基础设施层、应用服务层、领域层和表示层。阐述了各层的作用与相互关系,如领域层承载业务逻辑,应用服务层协调领域对象,基础设施层处理技术细节,表示层负责用户交互。通过实例分析,展示了如何组织代码以实现清晰的分层架构。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

### 工程结构划分
package:                com.company.业务.模块

--  application         粗粒度业务的入口,不包含复杂的业务规则,对下层进行协调,对业务逻辑进行编排
----  command           业务的增、删、改
------  cmd             请求参数对象
------  impl            command实现
----  query             业务的查询
------  converter       domain object 转换成 dto
------  dto             暴露给前端的数据对象
------  impl            query实现
------  qry             请求参数对象


--   domain             业务领域核心
----  aggregate         聚合根
----  entity            实体
----  valueobject       值对象
----  factory           领域对象的创建工厂
----  service           领域服务 不属于任何领域对象的行为
----  repository        资源库
----  event             领域事件 
------  listener        领域事件监听
------  publisher       领域事件发布
------  eventobject     领域事件模型
----  acl               anti corruption layer 防腐层,外部系统依赖
----  extenpoint


--   infrastructure     基础设施,提供底层的纯技术实现服务
----  db                数据库
------ repository       repository 实现
------  dataobject      数据对象(po)
------  converter       对象转换 (数据模型、领域模型)
------  mapper          mybatis(dao)
----  cache             缓存
------ repository       repository 实现
------  dataobject      数据对象
------  converter       对象转换 (数据模型、领域模型)
------  redis          redis
----  rpc               dubbo、thrift、http、、、
------ repository       repository 实现
------  dataobject      数据对象(dto)
------  converter       对象转换 (数据模型、领域模型)
----  mq                消息
------ producer         生产者
------ consumer         消费者
----  event             事件
------  publisher        事件发布者
------  listener         事件监听


--  common              公共依赖的 constant、properties  (各maven module 也可以有自己的common)
----  constants         常量
----  properties        基于配置的常量(迁配置中心后可动态刷新)
----  util              工具类
----  enums             枚举
----  dto               数据模型  ???


--  parent              treasurebase内部版本管理,以及依赖ea的父pom,repository等


--  api                 外部使用的sdk,如访问我们的spi服务  ?? api、client、sdk
----  dto               数据对象
----  util              工具类
----  service           服务调用


--  spi-app             对外提供服务的应用
----  rest              http 服务
----  rpc               dubbo、thrift 等服务
----  mq                消息监听
----  ws                web service 服务


--  task-app            任务作业调度的应用
----  job
----  


--  web-app             为前端UI提供服务的应用 (请求参数、响应数据取决于 application)
----  controller
----  validate
----  filter




--  adapter             请求、响应(同步)接口适配服务(接口、模型转换、鉴权、加签等)
--  callback            回调(异步)接口服务 (重试、幂等、回调记录等)
adapter、callback 合并???

ea-tools
--  ea-framework        基类、日志、异常、响应对象、分页、多语、时区、租户、加解密等
--  ea-redis            缓存
--  ea-swagger          接口文档
### 基于Spring Boot和DDD的项目结构设计最佳实践 在构建基于Spring Boot和领域驱动设计(DDD)的应用程序时,合理的项目结构对于实现清晰的功能划分至关重要。以下是关于如何设计这种项目的建议: #### 1. 层次化架构 典型的DDD应用可以分为以下几个层次[^1]: - **Domain Layer**: 这一层包含了核心业务逻辑以及实体、值对象和服务类。它是整个应用程序的核心部分。 - **Application Layer**: 提供高层次的服务接口来协调不同域之间的交互。这一层通常不包含具体的业务逻辑。 - **Infrastructure Layer**: 负责技术细节的处理,比如数据库访问、消息队列集成等。 - **Presentation Layer (Optional)**: 如果存在前端界面或者API网关,则此层负责接收外部请求并调用相应的服务。 #### 2. 模块划分 为了更好地遵循单一职责原则(SRP),推荐按照功能模块拆分包名而不是按传统的技术栈分类方式。例如,在`spring-boot-ddd`项目中可以看到如下目录布局[^2]: ```plaintext src/main/java/com/example/demo/ ├── application/ # 应用服务定义在此处 │ └── OrderService.java ├── domain/ # 领域模型放置在这里 │ ├── model/ # 实体与值对象 │ │ └── Product.java │ └── repository/ # 接口声明用于数据持久化操作 │ └── IProductRepository.java └── infrastructure/ # 技术实现放于此文件夹下 ├── persistence/ # 数据库映射关系及具体存储方案 │ └── JpaProductRepositoryImpl.java └── api/ # 对外暴露RESTful API端点 └── OrderController.java ``` 上述例子展示了如何通过不同的子包组织代码,使得每一部分都有明确的责任范围。 #### 3. 使用JPA进行ORM映射 当涉及到数据库交互时,可以利用Java Persistence API(JPA)完成对象关系映射工作。下面是一个简单的商品实体示例[^4]: ```java package cn.juwatech.domain; import javax.persistence.Entity; import javax.persistence.GeneratedValue; import javax.persistence.GenerationType; import javax.persistence.Id; @Entity public class Product { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private String name; private double price; // Constructors, getters, setters omitted for brevity. } ``` 这里我们创建了一个名为`Product`的实体,并标注了必要的元数据以便框架能够自动管理其生命周期。 #### 4. 上下文映射(Context Mapping) 如果系统规模较大且涉及多个独立运作但又相互关联的部分,则需要考虑上下文边界及其间的协作模式。可以通过显式的依赖注入或其他机制确保各组件间松耦合的同时又能高效沟通[^3]. --- ### 总结 综上所述,采用分层加模块化的策略可以帮助开发者更有效地管理和维护复杂的软件工程;同时借助成熟的工具链如Hibernate简化日常开发任务也能极大提升效率。 相关问题
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值