核心业务对象应从数据容器转变为封装行为与规则的富模型。1. 采用DDD指导建模，识别聚合根如Order、Account，封装领域逻辑于对象内部，使用值对象如Address、Money增强语义。2. 数据与行为共存于类中，通过order.cancel()等方法体现业务意图，由对象自身控制状态变更，私有方法拆分复杂逻辑。3. 构造函数校验必填项保证合法初始化，复杂创建用工厂方法隐藏细节，优先不可变设计提升安全性。4. 遵循单一职责，避免上帝对象，跨聚合逻辑交由领域服务如PaymentProcessor处理，副作用通过OrderCreatedEvent等事件机制解耦，组合策略类实现灵活扩展。围绕业务语义建模使代码贴近真实场景，提升系统可维护性与扩展性。
在Java开发中，核心业务对象的设计直接决定了系统的可维护性、扩展性和业务表达的清晰度。很多项目初期将数据与行为分离，比如使用贫血模型（Anemic Model），导致业务逻辑散落在服务层，对象仅作为数据容器，丧失了面向对象的优势。要真正发挥Java的面向对象能力，需要从“数据”向“数据+行为”的富模型转变，实现业务逻辑的内聚。
1. 以领域驱动设计（DDD）指导对象建模
领域驱动设计强调通过业务领域来组织代码结构，将核心业务对象视为领域模型的核心组成部分。这种设计方式帮助开发者聚焦于业务本质，而非技术细节。
- 识别聚合根（Aggregate Root）：确定哪些对象是业务操作的一致性边界，如订单Order、账户Account等，它们负责维护内部状态的一致性。
- 封装领域逻辑：将与某个对象相关的业务规则和行为封装在其内部，例如订单的“取消”操作应由Order对象自身完成，而不是由OrderService来控制其字段变更。
- 使用值对象（Value Object）表达语义：对于无唯一标识的属性组合，如地址Address、金额Money，定义为不可变的值对象，增强类型安全和语义表达。
2. 将行为与数据封装在同一类中
避免贫血模型的关键是让对象不仅持有数据，还具备操作这些数据的能力。这符合封装原则，提升代码的可读性和可测试性。
- 方法命名体现业务意图：如order.cancel()比orderService.updateStatus(order, CANCELLED)更具语义清晰性。
- 状态变更由对象自身控制：在调用行为方法时，对象内部校验是否满足执行条件，如只有待支付的订单才能被取消。
- 使用私有方法拆分复杂逻辑：将一个行为拆解为多个小步骤，保持public方法简洁，同时提高可维护性。
3. 利用构造函数和工厂方法保证对象一致性
核心业务对象在创建时就应处于合法状态，避免出现半成品或非法实例。
立即学习“Java免费学习笔记（深入）”；
- 构造函数中进行必要校验：确保必填字段非空、数值合理、状态合法等。
- 复杂创建过程使用工厂模式：当对象构建逻辑较复杂时，引入Factory类或静态工厂方法，隐藏创建细节，如Order.createFromCart(Cart cart)。
- 优先使用不可变设计：对于值对象或部分实体，采用final字段和私有构造，对外提供withXxx()风格的派生方法，提升线程安全性和可预测性。
4. 合理划分职责，避免上帝对象
虽然鼓励行为内聚，但也要防止一个类承担过多职责。应遵循单一职责原则，保持类的专注。
- 拆分领域服务处理跨对象逻辑：当操作涉及多个聚合或外部系统时，使用领域服务（Domain Service）协调，如PaymentProcessor处理支付流程。
- 事件机制解耦副作用：对象内部触发领域事件（如OrderCreatedEvent），由监听器处理发邮件、更新库存等后续动作，降低耦合。
- 善用组合而非继承：通过成员变量引入其他行为模块，比如Order包含一个OrderValidator策略类来执行不同场景下的校验规则。
基本上就这些。把核心业务对象从单纯的数据载体转变为承载行为和规则的活跃实体，是构建高质量Java系统的关键一步。关键是围绕业务语义建模，让代码更贴近真实世界，同时借助良好的封装和职责划分，保持系统的灵活性和健壮性。不复杂但容易忽略。
