设计对象模型应以职责为中心，围绕“做什么”拆分；2. 使用DDD模式划分实体、值对象、聚合与领域服务；3. 避免上帝对象与贫血模型，让行为内聚于对象；4. 通过依赖倒置与接口隔离解耦，明确方法归属，边界自然清晰。
在Java中构建具备边界清晰的对象模型，关键在于以职责为中心进行拆分。这意味着每个类的定义应围绕它“做什么”而不是“它是什么”来组织。这种方式能提升代码的可维护性、可测试性和扩展性。
明确职责：从行为出发设计类
传统建模常从数据结构入手，比如看到一张订单表就创建一个Order类，然后不断往里面添加字段和方法。但职责驱动的设计要求我们先问：这个对象要承担哪些责任？
例如，订单相关的操作可能包括：
- 计算总价
- 验证库存
- 生成发票
- 发送通知
这些职责并不都该由Order类独自承担。可以拆分为：
立即学习“Java免费学习笔记（深入）”；
Order（聚合根，管理状态）OrderCalculator（负责价格计算）
OrderValidator（校验业务规则）
OrderNotifier（处理通知逻辑）
这样每个类只关注一件事，职责清晰，便于替换或扩展。
使用领域驱动设计（DDD）指导拆分
DDD提供了一套有效的模式来划分职责：
- 实体（Entity）：具有唯一标识的对象，如Order、User
- 值对象（Value Object）：通过属性定义的对象，如Money、Address
- 聚合（Aggregate）：一组被视为整体的领域对象，Order可能是一个聚合根
- 领域服务（Domain Service）：当某个操作不属于任何单一对象时，用服务封装，如PaymentProcessor
- 工厂（Factory）与仓储（Repository）：分离对象创建和持久化逻辑
通过这些模式，你可以避免将所有逻辑塞进实体类中，保持聚合边界的干净。
避免上帝对象与贫血模型
常见误区是创建“全能类”，包含几十个字段和方法，这就是所谓的上帝对象。另一种极端是贫血模型——类只有get/set方法，业务逻辑全放在Service层。
更好的做法是：
- 让对象拥有自己的行为，比如order.cancel()而不是CancelService.cancel(order)
- 把跨多个对象的操作交给领域服务处理
- 使用私有方法封装内部逻辑，对外暴露有意义的行为接口
例如：
// 好的设计：行为内聚public class Order {
private OrderStatus status;
public void cancel(OrderCancellationPolicy policy) {
if (!policy.allowsCancellation(this)) {
throw new IllegalStateException("Cannot cancel");
}
this.status = OrderStatus.CANCELLED;
}
}
依赖倒置与接口隔离增强边界
为了进一步解耦，应依赖抽象而非实现。例如OrderNotifier不应直接依赖EmailService，而是依赖NotificationChannel接口。
这样可以在不修改核心逻辑的情况下切换短信、站内信等通知方式。
同时，为不同上下文提供专用接口，避免一个大接口被多方强制实现。
基本上就这些。关键是始终追问：这个方法真的属于这个类吗？如果换个场景它还能用吗？职责清晰了，边界自然就明确了。
