纯粹的业务对象应聚焦数据与核心行为，如订单判断发货条件或计算总价，避免持久化等外部职责；通过服务层处理保存、查询与通知，利用构造函数或工厂保证对象合法性，并在对象内封装业务逻辑如折扣计算，防止沦为仅含get/set的贫血模型，从而提升系统可维护性与扩展性。
在Java开发中，设计纯粹的业务对象（也叫领域对象或模型对象）是构建可维护、可扩展系统的关键。核心思路是让对象只关注“是什么”，而不是“怎么做”。这意味着业务对象应聚焦于数据和与之直接相关的逻辑，避免掺杂持久化、日志、事务控制等外部职责。
1. 保持业务对象专注数据与核心行为
一个纯粹的业务对象应该反映现实世界中的概念，比如“订单”、“用户”、“商品”。它包含属性和与这些属性直接相关的行为。
例如，一个订单对象可以判断自己是否满足发货条件，但不应负责调用数据库保存自身状态。
- 将字段封装为私有属性，提供合理的getter/setter（仅在需要时）
- 添加方法来表达业务规则，如 order.isOverdue() 或 order.calculateTotal()
- 避免在类中出现 save()、delete() 等持久化方法
2. 分离基础设施职责到服务层
当需要保存、查询或通知时，应由专门的服务类来处理。这样业务对象就不需要知道数据库、消息队列或网络的存在。
立即学习“Java免费学习笔记（深入）”；
- 使用 OrderService 来调用 orderRepository.save(order)
- 让 PaymentProcessor 处理支付逻辑，而不是写在 User 类里
- 通过事件机制（如 ApplicationEventPublisher）解耦后续动作，而非在对象内部发邮件或写日志
3. 使用构造函数和工厂保证对象完整性
确保创建对象时就处于合法状态，避免暴露无意义的默认构造器或允许中途破坏业务规则。
- 通过构造函数强制传入必要字段，如 new Order(customer, items)
- 复杂创建过程可用静态工厂方法或独立的工厂类
- 在构造时验证参数，抛出有意义的异常，如 IllegalArgumentException
4. 避免贫血模型与过度服务化
虽然要分离职责，但也不能走向另一个极端——把所有逻辑都移到服务类中，导致业务对象变成只有get/set的“数据容器”。
真正的纯粹对象不是空的，而是拥有属于它的逻辑。比如计算折扣、校验状态变更是否合法，这些都应放在对象内部。
- 允许 order.applyDiscount(discountRate) 修改自身状态
- 禁止从外部随意 set status，而应提供 order.cancel() 这样的语义化方法
- 状态变更逻辑内聚在类中，便于统一控制和测试
基本上就这些。关键是分清“这个逻辑是不是这个对象天生该懂的事”。如果是，就放进对象；如果不是，就交给协作方。这样出来的模型更清晰，也更容易应对变化。
