17370845950

设计对象模型应以职责为中心，围绕“做什么”拆分；2. 使用DDD模式划分实体、值对象、聚合与领域服务；3. 避免上帝对象与贫血模型，让行为内聚于对象；4. 通过依赖倒置与接口隔离解耦，明确方法归属，边界自然清晰。

在Java中构建具备边界清晰的对象模型，关键在于以职责为中心进行拆分。这意味着每个类的定义应围绕它“做什么”而不是“它是什么”来组织。这种方式能提升代码的可维护性、可测试性和扩展性。

明确职责：从行为出发设计类

传统建模常从数据结构入手，比如看到一张订单表就创建一个Order类，然后不断往里面添加字段和方法。但职责驱动的设计要求我们先问：这个对象要承担哪些责任？

例如，订单相关的操作可能包括：

• 计算总价
• 验证库存
• 生成发票
• 发送通知

这些职责并不都该由Order类独自承担。可以拆分为：

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接口。

这样可以在不修改核心逻辑的情况下切换短信、站内信等通知方式。

同时，为不同上下文提供专用接口，避免一个大接口被多方强制实现。

基本上就这些。关键是始终追问：这个方法真的属于这个类吗？如果换个场景它还能用吗？职责清晰了，边界自然就明确了。