一句话核心DDD领域驱动设计不是一套框架而是一种代码组织哲学。它要求你用代码直接翻译业务语言而不是把业务逻辑散落在增删改查CRUD里。对于Java开发者最经典的DDD范式就是**“四层架构” “六大战术模式”。为了让你秒懂我们把项目类比为“一家餐厅”**表现层Controller 服务员接收顾客指令。应用层Application 大堂经理调度任务发号施令。领域层Domain 厨师长 菜谱核心资产业务规则所在。基础设施层Infrastructure 冰箱、灶台数据库、Redis、MQ。下面我直接给你展示标准的Java DDD包结构和核心代码范式一看就懂。1. 标准的Java DDD包结构范式骨架com.example.order/ ├── interfaces/ # 表现层处理HTTP/RPC │ └── OrderController.java ├── application/ # 应用层用例编排无业务逻辑 │ ├── service/ # 应用服务如OrderApplicationService │ └── dto/ # 数据传输对象Request/Response ├── domain/ # 领域层核心只依赖Java本身不依赖Spring/DB │ ├── model/ # 领域模型 │ │ ├── aggregate/ # 聚合根如Order │ │ ├── entity/ # 实体如OrderItem │ │ └── vo/ # 值对象如Address, Money │ ├── service/ # 领域服务处理跨多个实体的复杂业务 │ └── repository/ # 仓储接口定义“我需要什么数据”不实现 └── infrastructure/ # 基础设施层实现Domain层的接口 ├── repository/ # 仓储实现JPA/MyBatis └── config/ # 配置类2. 六大战术模式Java代码实战为了便于理解我们模拟一个**“下单”**场景必须验证地址且订单总价要打折。① 值对象 (Value Object) —— 用record或不可变类特点没有唯一ID通过属性值判断相等性。封装业务规则。// 值对象地址publicrecordAddress(Stringprovince,Stringcity,Stringdetail){publicAddress{// 业务规则地址不能为空直接写在构造方法里if(provincenull||citynull){thrownewIllegalArgumentException(省市必填);}}}// 值对象金额publicclassMoney{privatefinalBigDecimalamount;privatefinalStringcurrency;// 通常用枚举// 封装加法逻辑而不是在Service里用BigDecimal算publicMoneyadd(Moneyother){...}}② 实体 (Entity) —— 有唯一ID可变Entity// 注意这里的注解是JPA的但DDD要求Domain层纯POJO所以通常把这个类放在infrastructure层做映射或者在Domain层不加Table注解。publicclassOrderItem{privateLongitemId;// 唯一标识privateStringproductName;privateIntegerquantity;privateMoneyprice;// 引用值对象}③ 聚合根 (Aggregate Root) ——DDD最重要的范式聚合根是外部访问聚合的唯一入口。比如“订单(Order)”和“订单项(OrderItem)”是整体外部只能操作Order不能直接修改OrderItem。// 领域层 - 聚合根publicclassOrder{privateLongorderId;// 唯一标识privateAddressshipAddress;// 值对象privateListOrderItemitems;// 实体集合privateOrderStatusstatus;// 核心业务方法充血模型业务逻辑写在实体内部而不是Service里publicvoidplaceOrder(){// 规则1下单必须校验地址封装在领域内部if(this.shipAddressnull){thrownewBusinessException(缺少收货地址);}// 规则2计算总价并打折满100减10MoneytotalcalculateTotal();if(total.amount().compareTo(newBigDecimal(100))0){// 打折逻辑...}this.statusOrderStatus.PLACED;// 发布领域事件可选DomainEventPublisher.publish(newOrderPlacedEvent(this.orderId));}// 计算总价也不允许Service插手由实体自己算privateMoneycalculateTotal(){returnitems.stream().map(OrderItem::getPrice).reduce(Money::add).orElse(...);}}④ 仓储接口 (Repository) ——依赖倒置的核心Domain层定义“我要什么”Infrastructure层实现“怎么拿”。// domain/repository/OrderRepository.java (接口)publicinterfaceOrderRepository{OrderfindById(Longid);voidsave(Orderorder);// 传入聚合根整个聚合一起保存}// infrastructure/repository/OrderRepositoryImpl.java (实现)RepositorypublicclassOrderRepositoryImplimplementsOrderRepository{AutowiredprivateOrderJpaMappermapper;// MyBatis或JPAOverridepublicvoidsave(Orderorder){// 1. 保存Order主表// 2. 保存OrderItem子表全部替换策略// 领域层不知道底层是MySQL还是Redis}}⑤ 领域服务 (Domain Service)当业务逻辑不属于某个具体的实体时使用比如转账涉及两个账户。// domain/service/TransferService.javapublicclassTransferService{publicvoidtransfer(Accountfrom,Accountto,Moneyamount){from.debit(amount);// 实体自己的方法to.credit(amount);}}⑥ 应用层 (Application Service) ——极薄的一层只做三件事拿数据、调领域方法、存数据。绝对不写 if-else 业务判断。// application/service/OrderAppService.javaServiceTransactionalpublicclassOrderAppService{privatefinalOrderRepositoryorderRepository;// 用例用户下单publicLongplaceOrder(PlaceOrderCommandcmd){// 1. 从仓储拿聚合根如果是新建则newOrderordernewOrder();// 2. 调用领域方法业务逻辑进入领域层order.placeOrder();// 3. 仓储保存orderRepository.save(order);// 4. 返回结果returnorder.getOrderId();}}3. 必须遵守的“铁律”DDD Java范式红线层级是否允许依赖Spring注解是否允许依赖数据库职责领域层 (Domain)❌ 禁止纯Java POJO❌ 禁止只写interface定义规则写业务逻辑方法应用层 (Application)✅ 允许 (Service)❌ 禁止编排用例调用领域方法事务发起点基础设施层 (Infra)✅ 允许 (Repository)✅ 允许实现接口处理SQL、Redis、MQ表现层 (Interfaces)✅ 允许 (RestController)❌ 禁止参数校验、返回JSON为什么领域层禁止用Spring注解因为DDD追求**“业务逻辑与技术解耦”**。如果Autowired进了Domain换用Quarkus或单元测试时就废了。Domain应该是可以脱离Spring直接用new Order().placeOrder()就能跑单元测试的。4. 贫血模型 vs 充血模型一眼辨别真假DDD传统CRUD贫血Order类只有getter/setter所有if/else全在OrderServiceImpl里。→这是假DDD。DDD范式充血Order类拥有placeOrder()、cancel()、calculateTotal()方法。OrderAppService只有寥寥几行调用。→这是真DDD。总结记住这张脑图表现层接收请求 →应用层从基础设施层拿到仓储接口的实现 → 交给领域层的聚合根执行业务方法内部包含实体和值对象的规则 → 应用层再通过仓储存回去。如果只是简单的增删改查请不要用DDD杀鸡用牛刀。但如果业务逻辑极其复杂如电商、金融、医疗这个Java范式就是防止代码腐烂的最强武器。记住核心口诀“让代码说业务的话让数据库滚去基础设施层”。
