当前位置： 首页 > news >正文

DDD架构演进：从三层架构到领域驱动设计实践

news 2026/7/20 21:09:59

1. DDD落地实践概述

领域驱动设计（Domain-Driven Design，简称DDD）作为一种软件设计方法论，已经逐渐成为复杂业务系统开发的主流选择。但很多团队在实际落地过程中，往往陷入"理论很美好，实践很骨感"的困境。本文将从一个典型的三层架构出发，逐步演化为符合DDD理念的应用架构，并通过Maven Archetype工具实现项目模板化，最后以一个CMS系统为例展示完整实现。

对于刚接触DDD的开发者来说，最大的困惑莫过于如何将那些抽象的概念（如聚合根、值对象、仓储等）转化为具体的代码结构。我在多个大型项目中实践DDD后发现，与其一开始就追求完美的架构设计，不如从现有项目结构出发，通过渐进式重构来引入DDD元素。这种方式既能保证项目持续交付，又能让团队逐步掌握DDD精髓。

2. 从三层架构到DDD架构的演进

2.1 传统三层架构的问题分析

典型的三层架构包含Controller、Service和DAO层，这种结构简单明了，在小项目中表现良好。但随着业务复杂度提升，其弊端逐渐显现：

// 典型贫血模型的Service代码 public class OrderService { @Transactional public void createOrder(OrderDTO dto) { // 参数校验 if (dto.getItems() == null || dto.getItems().isEmpty()) { throw new IllegalArgumentException("订单项不能为空"); } // 数据库操作 Order order = new Order(); order.setUserId(dto.getUserId()); order.setStatus("CREATED"); orderMapper.insert(order); // 业务逻辑 for (OrderItemDTO item : dto.getItems()) { if (item.getQuantity() <= 0) { throw new IllegalArgumentException("数量必须大于0"); } OrderItem orderItem = new OrderItem(); orderItem.setOrderId(order.getId()); orderItem.setProductId(item.getProductId()); orderItem.setQuantity(item.getQuantity()); orderItemMapper.insert(orderItem); } // 调用外部服务 inventoryClient.deductStock(dto.getItems()); } }

这种代码的问题在于：

  1. 业务逻辑分散在Service方法中，难以复用
  2. 领域知识被埋没在技术细节里
  3. 单元测试需要mock大量依赖
  4. 变更影响范围难以控制

2.2 领域模型的引入

解决上述问题的关键是引入领域模型，将业务逻辑封装到领域对象中。我们首先定义Order聚合根：

public class Order { private Long id; private String userId; private List<OrderItem> items; private String status; public static Order create(String userId, List<OrderItem> items) { if (items == null || items.isEmpty()) { throw new DomainException("订单项不能为空"); } Order order = new Order(); order.userId = userId; order.items = new ArrayList<>(items); order.status = "CREATED"; return order; } public void addItem(Product product, int quantity) { if (quantity <= 0) { throw new DomainException("数量必须大于0"); } this.items.add(new OrderItem(product.getId(), quantity)); } // 其他业务方法... }

改造后的Service方法变得简洁：

public class OrderApplicationService { private final OrderRepository orderRepository; private final InventoryClient inventoryClient; @Transactional public void createOrder(OrderCommand command) { List<OrderItem> items = command.getItems().stream() .map(dto -> new OrderItem(dto.getProductId(), dto.getQuantity())) .collect(Collectors.toList()); Order order = Order.create(command.getUserId(), items); orderRepository.save(order); inventoryClient.deductStock(command.getItems()); } }

2.3 仓储模式的实现

仓储(Repository)是连接领域模型和数据持久化的桥梁，其核心是隐藏持久化细节：

public interface OrderRepository { Order findById(OrderId id); void save(Order order); } @Repository public class OrderRepositoryImpl implements OrderRepository { private final OrderMapper orderMapper; private final OrderItemMapper itemMapper; @Override public Order findById(OrderId id) { OrderDO orderDO = orderMapper.selectById(id.getValue()); if (orderDO == null) return null; List<OrderItemDO> itemDOs = itemMapper.selectByOrderId(id.getValue()); List<OrderItem> items = itemDOs.stream() .map(do -> new OrderItem(do.getProductId(), do.getQuantity())) .collect(Collectors.toList()); return Order.reconstitute( new OrderId(orderDO.getId()), orderDO.getUserId(), items, orderDO.getStatus() ); } @Override @Transactional public void save(Order order) { if (order.getId() == null) { OrderDO orderDO = new OrderDO(); orderDO.setUserId(order.getUserId()); orderDO.setStatus(order.getStatus()); orderMapper.insert(orderDO); order.setId(new OrderId(orderDO.getId())); } else { // 更新逻辑... } // 处理items... } }

注意：仓储接口应定义在领域层，而实现在基础设施层。仓储方法的参数和返回值应该是领域对象或基本类型，而不是持久化对象。

3. 完整应用架构设计

3.1 分层架构详解

经过演进后，我们得到的分层架构如下：

myapp ├── launcher # 启动模块 ├── ui-web # 用户接口层(Web) ├── application # 应用层 ├── domain # 领域层 │ ├── model # 领域模型 │ ├── service # 领域服务 │ └── repository # 仓储接口 └── infrastructure # 基础设施层 ├── persistence # 持久化实现 ├── gateway # 外部服务调用 └── cache # 缓存实现

各层职责明确：

  1. 用户接口层(ui)：处理外部请求，包括REST API、RPC服务、消息订阅等
  2. 应用层(application)：协调领域对象完成用例，处理事务、安全等横切关注点
  3. 领域层(domain)：包含核心业务逻辑，由实体、值对象、聚合根、领域服务等组成
  4. 基础设施层(infrastructure)：提供技术实现，如数据库访问、消息队列、缓存等

3.2 关键设计原则

  1. 依赖方向：高层模块不应依赖低层模块，依赖关系应该指向抽象。具体表现为：

    • 领域层不依赖任何其他层
    • 应用层依赖领域层
    • 基础设施层实现领域层定义的接口

  2. 防腐层设计：对外部系统的调用需要通过防腐层进行隔离：

// 领域层定义接口 public interface InventoryService { boolean isStockEnough(String productId, int quantity); } // 基础设施层实现 public class InventoryServiceImpl implements InventoryService { private final InventoryClient client; @Override public boolean isStockEnough(String productId, int quantity) { InventoryDTO dto = client.getInventory(productId); return dto.getAvailable() >= quantity; } }
  1. CQRS模式：对于复杂查询，可以绕过领域模型直接访问数据库：
public class OrderQueryService { private final OrderMapper orderMapper; public Page<OrderDTO> queryOrders(OrderQuery query) { List<OrderDO> orders = orderMapper.selectByQuery(query); return new Page<>( orders.stream().map(this::toDTO).collect(Collectors.toList()), orderMapper.countByQuery(query) ); } }

4. 使用Maven Archetype创建项目骨架

4.1 Archetype工程结构

我们将上述架构实现为Maven Archetype，主要包含以下模块：

ddd-archetype ├── pom.xml ├── src │ └── main │ └── resources │ ├── archetype-resources │ │ ├── launcher │ │ ├── domain │ │ ├── application │ │ ├── ui-web │ │ └── infrastructure │ └── META-INF │ └── maven └── archetype.properties

4.2 安装和使用步骤

  1. 克隆项目并安装到本地Maven仓库：
git clone https://github.com/feiniaojin/ddd-archetype.git cd ddd-archetype mvn archetype:create-from-project -Darchetype.properties=archetype.properties cd target/generated-sources/archetype mvn install
  1. 使用Archetype创建新项目：
mvn archetype:generate \ -DarchetypeGroupId=com.feiniaojin \ -DarchetypeArtifactId=ddd-archetype \ -DarchetypeVersion=1.0.0 \ -DgroupId=com.example \ -DartifactId=myapp \ -Dversion=1.0.0-SNAPSHOT
  1. 生成的项目结构已经包含了：
    • 分层模块划分
    • 基础依赖配置(Spring Boot, Spring Data JDBC等)
    • 示例领域模型和仓储
    • 统一异常处理
    • 日志和监控切面

5. CMS系统实现案例

5.1 领域模型设计

以简单的CMS系统为例，核心领域模型包括：

// 文章聚合根 public class Article { private ArticleId id; private String title; private String content; private ArticleStatus status; private List<Comment> comments; public static Article create(String title, String content) { // 验证逻辑... return new Article(title, content); } public void publish() { if (this.status != ArticleStatus.DRAFT) { throw new DomainException("只有草稿状态的文章可以发布"); } this.status = ArticleStatus.PUBLISHED; } public void addComment(String content, String userId) { this.comments.add(Comment.create(content, userId)); } } // 值对象 public class ArticleId implements ValueObject { private final String value; public ArticleId(String value) { if (value == null || value.length() != 32) { throw new IllegalArgumentException("无效的文章ID"); } this.value = value; } public String getValue() { return value; } }

5.2 仓储实现

使用Spring Data JDBC实现仓储：

public interface ArticleRepository { Article findById(ArticleId id); void save(Article article); } @Repository public class ArticleRepositoryImpl implements ArticleRepository { private final ArticleJdbcRepository jdbcRepo; @Override public Article findById(ArticleId id) { return jdbcRepo.findById(id.getValue()) .map(this::toDomain) .orElse(null); } @Override @Transactional public void save(Article article) { ArticleDO articleDO = toDO(article); if (jdbcRepo.existsById(articleDO.getId())) { jdbcRepo.update(articleDO); } else { jdbcRepo.insert(articleDO); } // 处理comments... } }

5.3 应用服务

协调领域对象完成业务用例：

@Service public class ArticleApplicationService { private final ArticleRepository articleRepo; private final EventPublisher eventPublisher; @Transactional public ArticleId createDraft(String title, String content) { Article article = Article.create(title, content); articleRepo.save(article); return article.getId(); } @Transactional public void publishArticle(ArticleId id) { Article article = articleRepo.findById(id); if (article == null) { throw new ApplicationException("文章不存在"); } article.publish(); articleRepo.save(article); eventPublisher.publish(new ArticlePublishedEvent(id)); } }

6. 实践中的经验与教训

6.1 常见问题及解决方案

  1. 贫血模型陷阱：

    • 现象：领域对象只有getter/setter，业务逻辑仍在Service中
    • 解决：通过代码审查确保业务逻辑内聚到领域对象

  2. 聚合设计过大：

    • 现象：一个聚合包含过多实体，导致并发冲突
    • 解决：根据业务一致性边界重新划分聚合

  3. 仓储实现复杂：

    • 现象：为支持复杂查询，仓储方法参数膨胀
    • 解决：引入Specification模式或单独使用QueryService

6.2 性能优化技巧

  1. 懒加载实现：
public class Article { private transient CommentRepository commentRepo; public List<Comment> getComments() { if (this.comments == null) { this.comments = commentRepo.findByArticleId(this.id); } return this.comments; } }
  1. CQRS优化查询：
public class ArticleQueryService { private final ArticleMapper mapper; public Page<ArticleView> queryArticles(ArticleQuery query) { List<ArticleDO> list = mapper.selectByQuery(query); return new Page<>( list.stream().map(this::toView).collect(Collectors.toList()), mapper.countByQuery(query) ); } }

6.3 测试策略

  1. 领域模型测试：
class ArticleTest { @Test void should_throw_when_publish_non_draft() { Article article = new Article("test", "content"); article.publish(); assertThrows(DomainException.class, () -> article.publish()); } }
  1. 应用服务测试：
@ExtendWith(MockitoExtension.class) class ArticleApplicationServiceTest { @Mock private ArticleRepository repo; @InjectMocks private ArticleApplicationService service; @Test void should_publish_article() { Article article = new Article("test", "content"); when(repo.findById(any())).thenReturn(article); service.publishArticle(new ArticleId("1")); assertTrue(article.isPublished()); verify(repo).save(article); } }

7. 进阶方向建议

当团队已经掌握基础DDD实现后，可以进一步探索：

  1. 事件驱动架构：使用领域事件实现系统解耦
  2. Saga模式：管理跨聚合的长事务
  3. 微服务划分：基于限界上下文划分服务边界
  4. 领域特定语言(DSL)：通过API设计体现通用语言

我在实际项目中发现，DDD落地最难的不是技术实现，而是团队思维方式的转变。建议从小的功能模块开始实践，逐步扩大范围，同时要重视领域专家与开发人员的持续沟通，才能真正发挥DDD的价值。

http://www.jsqmd.com/news/1230421/

相关文章：

  • UI-TARS桌面版：基于视觉语言模型的GUI自动化5大架构深度解析与实战部署指南
  • 2026 年新发布：潜江比较好的管道保温聚氨酯黑白料制造企业推荐,用它，管道保暖成本竟能砍掉一半？ - 行业推荐官[官方】--
  • 机器学习生产化：从模型指标到系统韧性的工程实践
  • Ubuntu rootfs构建指南：从基础到定制化系统
  • AM263P UART红外通信：从SIR到CIR，嵌入式开发的硬件协议栈详解
  • [具身智能-595]：RDK X5 如何支持 4G/5G 模块
  • 西安智界V9内饰升级哪家靠谱？车宫管一站式升级全攻略 - 互联网科技品牌测评
  • TI AM64x/AM243x集成以太网交换机CPSW3G架构、配置与实战调试指南
  • 温度采样与生成参数：如何配置distilgpt2 MLX获得最佳文本输出
  • 开发者必看：OpenVINO™ AI Plugins for GIMP插件架构与代码实现原理
  • 解决PVE集群中Ceph存储导致的VNC访问问题
  • 雷达官方更换原装表带价格查询｜网点地址和电话权威信息公告（2026年7月最新） - 亨得利官方服务中心
  • 小程序计算机毕设之基于 Android 的托管食堂就餐管理系统 学生小餐桌订餐签到管理系统的设计与实现(完整前后端代码+说明文档+LW，调试定制等）
  • 苹果M1 iMac深度评测：性能、设计与使用体验
  • (Redis基础教程之十二) 如何解决Redis中的故障
  • Geo优化系统源代码部署技巧及流程分享
  • AI 时代的知识库：企业效率提升的五大关键优势
  • 国产大模型哪个更适合企业内部落地？
  • 如何让老款Mac焕发新生：OpenCore Legacy Patcher详细使用指南
  • 7.20
  • 5分钟掌握：Windows消息防撤回终极方案
  • 南极科考关键技术解析：钻探与生态监测的创新突破
  • linux基于wifi，Xshell的远程连接
  • 2026年深圳消杀行业图谱：五强品牌服务能力全景对比 - 信息热点
  • 如何在 CoreOS 中部署 systemd-docker：完整部署流程与配置示例
  • Meta裁员反思：组织效率提升的关键在流程优化而非简单减员
  • 鸿蒙 ArkTS 实战：Life Time Account 从人生时间账户到个人效率工具完整解析
  • 哪款ai写小说软件最好用？2026年10款ai写小说软件深度测评
  • 2026年7月最新雅典温州吾悦广场维修保养服务电话 - 亨得利钟表维修中心
  • 2026年7月寄大件物流推荐便宜到离谱的真香榜单 - 生活情报姬