领域对象承载业务含义与行为逻辑，数据对象仅负责结构化传输或持久化映射；前者如Order封装校验、不变量和行为，后者如OrderEntity、OrderDTO等仅描述结构且需显式转换。
领域对象（Domain Object）和数据对象（Data Object）在Java项目中常被混淆，但二者职责截然不同：领域对象承载业务含义与行为逻辑，数据对象仅负责数据的结构化传输或持久化映射。区分不清容易导致贫血模型、业务逻辑散落、可维护性下降。
领域对象：表达“业务是什么”和“能做什么”
领域对象是业务领域的核心抽象，比如Order、Customer、Inventory。它不只是字段集合，更应封装业务规则、状态约束和行为方法。
- 包含校验逻辑：如order.place()需检查库存、支付状态、用户信用额度
- 体现不变量（invariant）：如“已发货的订单不能取消”应由对象自身控制
- 不依赖框架注解（如@Entity、@Table），避免与持久层耦合
- 通常位于domain或model包下，不直接暴露给外部接口
数据对象：专注“数据怎么存”和“怎么传”
数据对象是技术实现层面的载体，常见类型包括：Entity（JPA实体）、DTO（数据传输对象）、VO（视图对象）、DAO（数据访问对象）等。它们只描述结构，不含业务逻辑。
- Entity：与数据库表一一映射，含@Id、@Column等JPA注解，用于ORM操作
- DTO：用于跨层（如Controller → Service）或跨系统传递，字段精简、无行为，常配合MapStruct做转换
- VO：面向前端展示，可能聚合多个领域对象字段，含格式化字段（如createTimeStr）
- 命名建议带后缀：如OrderEntity、OrderDTO、OrderVO，避免歧义
分层协作：用转换隔离关注点
领域对象不直接转成DTO或Entity，中间必须有显式转换（手动set或工具类）。这是防止业务逻辑泄漏的关键防线。
立即学习“Java免费学习笔记（深入）”；
- Service层使用领域对象处理业务，完成后通过Converter或Mapper转为DTO返回
- Repository层接收Entity做CRUD，再将其转换为领域对象供Service使用
- 禁止在Entity里写getTotalAmount()这类业务方法——它属于领域对象
- 可借助Lombok的@Builder或MapStruct减少样板代码，但不掩盖职责边界
一个典型流转示例
用户下单场景中：
- Controller接收OrderDTO（含商品ID、数量、收货地址）
- Service将DTO转为Order领域对象，调用order.confirm()执行库存扣减、价格计算、风控校验
- Repository将Order转为OrderEntity并保存到数据库
- Service返回新构建的OrderVO（含订单号、状态文案、预计送达时间）给前端
