基于业务上下文的同一实体多聚合根DDD设计咨询（.NET C#）

核心思路：基于子域拆分聚合，避免跨场景数据耦合 #

你的问题本质是单一聚合根承载了多场景的业务职责，导致数据过度加载和边界模糊。直接把所有关联实体塞进Company聚合根是典型的“贫血模型转充血模型”的误区，正确的做法是从子域划分和聚合边界定义入手：

1. 拆分子域，定义场景化的聚合根 #

按照业务场景拆分出两个独立子域：

• 财务/发票子域：聚焦企业服务的计费、发票生成逻辑
• 车辆管理子域：聚焦企业车辆的绑定、展示逻辑

在每个子域中，分别定义适配场景的聚合根，只保留当前场景必需的关联数据：

// 财务子域的企业聚合根：仅关联业务服务
public class CompanyBusinessAggregateRoot
{
    public int Id { get; set; }
    public string Name { get; set; }
    // 仅在财务场景需要的业务服务集合
    public IReadOnlyCollection<BusinessService> BusinessServices { get; private set; }

    // 财务场景专属业务方法
    public Invoice GenerateInvoice(DateTime billingPeriod)
    {
        // 基于BusinessServices计算金额、生成发票的逻辑
    }
}

// 车辆管理子域的企业聚合根：仅关联车辆
public class CompanyVehicleAggregateRoot
{
    public int Id { get; set; }
    public string Name { get; set; }
    // 仅在车辆场景需要的车辆集合
    public IReadOnlyCollection<Vehicle> Vehicles { get; private set; }

    // 车辆场景专属业务方法
    public void BindVehicle(Vehicle vehicle)
    {
        // 校验车辆归属、重复绑定等逻辑
    }
}

// 子域共享的基础实体（无需作为聚合根）
public class BusinessService
{
    public int Id { get; set; }
    public int CompanyId { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; } // 建议用decimal替代double处理金额，避免精度问题
}

public class Vehicle
{
    public int Id { get; set; }
    public int CompanyId { get; set; }
    public string CarPlate { get; set; }
}

2. 跨场景数据的处理方式 #

两个子域的Company聚合根共享同一个Id（对应数据库中的同一家企业），但各自只加载自身场景需要的数据，避免冗余。如果需要跨场景展示数据（比如同时显示企业名称和绑定车辆），可以通过应用层组合数据，而非在聚合根中强行关联。

3. 临时优化方案：仓储层按需加载 #

如果暂时不想拆分子域，也可以通过仓储层的按需加载策略缓解问题：

• 定义不同的仓储接口，比如ICompanyBusinessRepository和ICompanyVehicleRepository，分别实现加载包含BusinessServices或Vehicles的Company实例。
• 应用层根据具体场景调用对应仓储，避免一次性加载所有关联数据。

但这种方案只是临时优化，长期来看子域拆分更符合DDD的边界设计原则，能从根源上避免聚合根职责膨胀。

内容的提问来源于stack exchange，提问作者lasjan