1. DDD落地实践概述领域驱动设计Domain-Driven Design简称DDD作为一种软件设计方法论在复杂业务系统开发中越来越受到重视。但很多团队在实际落地时常常陷入理论很美好实践很骨感的困境。本文将从一个典型的三层架构出发逐步演化为符合DDD理念的应用架构并分享如何将其固化为Maven Archetype模板。为什么需要DDD在传统贫血模型中业务逻辑散落在各个Service方法里导致代码难以维护和扩展。通过DDD的领域模型封装核心业务规则可以显著提升代码的可读性和可维护性。特别是在业务复杂度高的系统中DDD的优势更为明显。2. 从三层架构到DDD架构的演进2.1 初始三层架构分析典型的三层架构包含Controller层处理HTTP请求和响应Service层业务逻辑处理DAO层数据库访问这种架构的主要问题是Service层逐渐变成上帝类包含所有业务规则导致代码臃肿难以维护业务规则重复分散单元测试困难2.2 第一步模型与DAO层合并将贫血的数据模型合并到DAO层因为数据模型仅作为属性容器没有业务逻辑与数据库表结构强耦合主要服务于DAO层的ORM操作合并后结构更清晰避免了模型类在不同层之间的无意义传递。2.3 第二步抽取领域模型将业务逻辑从Service中抽离封装到领域模型中。改造前后的Service方法对比改造前public void bizLogic(Param param) { // 参数校验 // 数据查询 // 业务规则判断 // 数据组装 // 持久化操作 }改造后public void bizLogic(Param param) { // 参数校验 Domain domain loadDomain(param); domain.doBusinessLogic(param); saveDomain(domain); }领域模型的优势业务规则内聚避免重复代码更易测试2.4 第三步引入Repository模式Repository负责聚合根的持久化和加载其关键特征接口定义在领域层实现依赖基础设施屏蔽持久化细节典型Repository接口public interface OrderRepository { Order findById(OrderId id); void save(Order order); }2.5 第四步架构分层细化最终形成的四层架构用户接口层(UI)处理外部请求应用层(Application)协调领域对象领域层(Domain)核心业务逻辑基础设施层(Infrastructure)技术实现各层职责明确通过依赖倒置解耦。3. Maven Archetype实现3.1 Archetype工程结构标准DDD项目包含以下模块ddd-example ├── launcher # 启动模块 ├── ui-web # Web接口 ├── application # 应用服务 ├── domain # 领域模型 └── infrastructure # 基础设施3.2 Archetype创建步骤克隆模板项目git clone https://github.com/feiniaojin/ddd-archetype.git生成Archetypemvn archetype:create-from-project安装到本地仓库cd target/generated-sources/archetype mvn install3.3 使用Archetype创建项目在IDE中选择ddd-archetype输入项目信息即可生成标准DDD项目结构。4. CMS系统实现案例4.1 领域模型设计核心聚合根Article文章Category分类Comment评论值对象Content文章内容Title标题4.2 Repository实现基于Spring Data JDBC的实现示例public class ArticleRepositoryImpl implements ArticleRepository { private final JdbcTemplate jdbcTemplate; Override public Article findById(ArticleId id) { // 查询并组装领域对象 } }4.3 应用服务协调领域对象完成业务用例public class ArticleApplicationService { public void publishArticle(PublishCommand command) { Article article articleFactory.create(command); articleRepository.save(article); eventPublisher.publish(new ArticlePublishedEvent(article.getId())); } }5. 落地经验与避坑指南5.1 常见问题领域模型变成贫血模型Plus症状只有getter/setter方法解决确保业务逻辑内聚Repository过度抽象症状通用CRUD接口解决按聚合根设计专用接口领域服务滥用症状领域服务变成新的Service层解决优先考虑实体行为5.2 性能优化技巧延迟加载public class Order { private CustomerId customerId; Transient private Customer customer; public Customer getCustomer() { if(customer null) { customer customerRepository.findById(customerId); } return customer; } }CQRS模式命令端领域模型处理查询端直接数据查询5.3 测试策略领域模型测试纯单元测试不依赖外部资源应用服务测试模拟Repository验证流程正确性集成测试测试完整调用链验证基础设施配置6. 进阶实践建议限界上下文划分按业务能力拆分明确上下文边界领域事件应用解耦领域逻辑实现最终一致性防腐层设计隔离外部系统影响转换外部模型实际项目中我们通过事件风暴工作坊识别核心领域概念再逐步细化模型设计。初期可以从小模块开始实践积累经验后再扩大范围。