1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

没有聚合会怎样？

  一个订单 Order，里面有若干订单项 OrderItem。
  如果没有边界规则：
    - 谁都能 new 一个 OrderItem 塞进去
    - 谁都能改 OrderItem 的数量、价格
    - 订单总价 = 各项小计之和，这个规则谁来保证？

  结果：
    → 任何一处漏改，总价就算错（不变量被破坏）
    → 业务规则散落各处，谁也不敢动
    → 并发修改互相覆盖

  聚合要解决的，就是"怎么让一组对象的规则不被绕过"。

1
2
3
4
5

聚合的本质：
  把"必须一起保持一致"的对象圈起来，
  指定一个入口（聚合根），
  所有修改只能从入口进，
  规则在入口内部强制，外界绕不过去。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

聚合（Aggregate）
  一组作为整体被访问和持久化的领域对象。
  它是一个"一致性边界"——边界内的对象，在任何时刻都满足业务规则。

聚合根（Aggregate Root）
  聚合的入口对象，是外部访问聚合的唯一通道。
  - 聚合外部的代码，只能持有聚合根的引用
  - 不能直接引用聚合内部的子对象
  - 所有对内部的修改，必须经过聚合根的方法

  例：订单聚合
    Order（聚合根）
    ├── OrderItem（内部实体）
    └── ShippingAddress（内部值对象）

    外部代码：
      order.AddItem(...)        ✅ 经过聚合根
      order.Items[0].Qty = 5    ❌ 绕过聚合根直接改内部

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

聚合根要承担四件事：

  1. 守门人
     所有修改入口都在它身上（AddItem / Cancel / Ship ...）
     内部对象不暴露可变状态（返回只读集合、值对象不可变）

  2. 不变量维护者
     业务规则在聚合根方法内部强制
     例：总价 = Σ小计；库存≥0；状态只能正向流转
     → 任何修改完成后，聚合一定处于"合法"状态

  3. 身份与标识
     持有聚合的唯一 ID（OrderId）
     外部对聚合的引用，只用 ID，不持有对象

  4. 领域事件的发布者
     完成一次合法修改后，发出领域事件
     （例：OrderPlaced）供外部订阅

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

原则 1：尽量设计小聚合
  错：把 User + 所有 Order + 所有 Review 塞进"用户聚合"
    → 改一个评论要锁整个用户，并发灾难
  对：聚合只包含"必须一起变更"的对象
    Order 聚合 = Order + OrderItem；Review 单独一个聚合
  越小越好，一个聚合根 + 少量子对象是理想形态。

原则 2：跨聚合引用，只引用 ID
  Order 持有 CustomerId，不持有 Customer 对象
  → 解耦，避免加载一个聚合时拖出整张对象图
  → 需要客户信息？另查，或读侧投影（第五篇 CQRS 讲）

原则 3：一个事务只修改一个聚合
  跨聚合的变更 → 用领域事件 + 最终一致，不在一个事务里硬保
  → 这就是微服务系列第五篇 Saga / 事件驱动的由来
  → 聚合边界 = 事务边界 = 一致性边界（三位一体）

原则 4：内部强一致，跨聚合最终一致
  聚合内：规则立即满足（强一致）
  聚合间：通过事件异步对账（最终一致）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

判断一组对象是不是该在一个聚合里，用这个问题：

  "这几个对象，是否必须在一个事务里一起改，才能保证正确？"

  是 → 同一个聚合
  否 → 拆成不同聚合，用事件联动

  举例验证：
    Order 和 OrderItem：
      改订单项数量，必须同时重算订单总价 → 同一聚合 ✅
    Order 和 Customer：
      下单时记录客户即可，改订单不影响客户 → 不同聚合（用 CustomerId）✅
    Order 和 Inventory：
      下单要扣库存，但"扣库存"是库存聚合自己的事
      → 不同聚合，用 OrderPlaced 事件通知库存聚合 ✅
    Order 和 Payment：
      支付是独立的，订单只关心"是否已支付"
      → 不同聚合，事件联动 ✅

1
2
3
4
5

一个常被问的问题：订单项算实体还是聚合？
  OrderItem 有自己的 ID，是"实体"，
  但它离开订单没有意义（没有"游离的订单项"），
  所以它不是独立聚合，而是 Order 聚合的内部实体。
  → 有 ID ≠ 是聚合。是否独立可被外部直接访问，才决定它是不是聚合根。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

聚合作为一个整体被存取：

  加载：一次把整个聚合（聚合根 + 子对象）从库里捞出来
  保存：一次把整个聚合写回

  仓储（Repository）按"聚合根"建，不按"表"建：
    IOrderRepository.Save(order)   // 存整个订单（含订单项）
    IOrderRepository.Find(orderId) // 取整个订单

  EF Core 里：一个聚合根对应一个 DbSet，子对象用 Owned / 导航属性一起加载。
  → 不要为 OrderItem 单独建仓储/DbSet（它不独立）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

多个请求同时改一个聚合，怎么不互相覆盖？

  首选：乐观锁（版本号）
    聚合带一个 Version 字段
    UPDATE ... WHERE Id = ? AND Version = ?
    → 有人在 你 之后 改过？Version 变了，你的更新影响 0 行 → 冲突，重试或报错

  为什么乐观锁够用：
    聚合边界小，冲突概率低
    而且我们坚持"一事务一聚合"，锁的范围本来就小

  EF Core：[Timestamp] / IsRowVersion() 自动生成乐观锁

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

// 强类型 ID（避免基础类型误用）
public readonly record struct OrderId(Guid Value);
public readonly record struct ProductId(Guid Value);

// 聚合根
public class Order : Entity<OrderId>, IAggregateRoot
{
    private readonly List<OrderItem> _items = new();
    public IReadOnlyCollection<OrderItem> Items => _items.AsReadOnly();
    public OrderStatus Status { get; private set; }
    public Address ShippingAddress { get; private set; }
    private int _version;          // 乐观锁版本号

    // 仓储加载/EF Core 用，不对外
    private Order(OrderId id, Address shipTo) : base(id)
    {
        Status = OrderStatus.Draft;
        ShippingAddress = shipTo;
    }

    // 工厂：创建即合法（保证不变量）
    public static Order Place(OrderId id, Address shipTo, IEnumerable<(ProductId, Money, int)> lines)
    {
        var order = new Order(id, shipTo);
        foreach (var (pid, price, qty) in lines)
            order.AddItem(pid, price, qty);   // 复用规则
        if (!order._items.Any())
            throw new DomainException("订单至少要有一项");
        order.Status = OrderStatus.Placed;
        return order;
    }

    // 所有修改入口：内部强制不变量
    public void AddItem(ProductId product, Money price, int qty)
    {
        if (Status != OrderStatus.Draft)
            throw new DomainException("非草稿态不能加项");
        if (qty <= 0) throw new DomainException("数量必须 > 0");
        if (price.Amount <= 0) throw new DomainException("价格必须 > 0");

        var existing = _items.FirstOrDefault(i => i.ProductId == product);
        if (existing is not null) existing.Increase(qty);     // 内部实体也只暴露方法
        else _items.Add(new OrderItem(product, price, qty));
    }

    public void Cancel()
    {
        if (Status >= OrderStatus.Shipped)
            throw new DomainException("已发货不能取消");
        Status = OrderStatus.Cancelled;
        // 发领域事件（第四篇展开）
        AddDomainEvent(new OrderCancelled(Id));
    }

    // 派生值：不变量的体现，不存储
    public Money Total => _items.Aggregate(
        new Money(0m, _items[0].Price.Currency),
        (sum, i) => sum.Add(i.SubTotal));
}

// 内部实体：不独立、不对外，只通过聚合根改
public class OrderItem : Entity<Guid>
{
    public ProductId ProductId { get; }
    public Money Price { get; }
    public int Qty { get; private set; }
    public Money SubTotal => new(Price.Amount * Qty, Price.Currency);  // 派生

    internal void Increase(int n)   // internal，外部调不到
    {
        if (n <= 0) throw new DomainException("增量必须 > 0");
        Qty += n;
    }
}

public enum OrderStatus { Draft, Placed, Paid, Shipped, Cancelled }

1
2
3
4
5
6
7
8

这段代码体现了全部原则：
  - 聚合根守门：_items 私有，只暴露 AsReadOnly，外部改不了
  - 不变量：AddItem 内校验数量/价格/状态；Total 永远 = Σ小计
  - 工厂保证创建即合法（空订单建不出来）
  - 内部实体 OrderItem 的修改方法 internal，只能被聚合根调
  - 跨聚合用 ID：OrderId/ProductId，不持有对方对象
  - 领域事件：Cancel 后发 OrderCancelled，不直接去改别的聚合
  - 乐观锁：_version 字段

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

错误 1：大聚合（God Aggregate）
  把所有相关对象塞一个聚合 → 锁大、并发差、加载慢
  → 回到原则 1：小聚合，跨聚合用 ID + 事件

错误 2：贫血聚合
  聚合根只有 getter/setter，规则写在 Service 里
  → 不变量形同虚设。规则必须在聚合根方法内。

错误 3：跨聚合事务
  为了"图省事"，一个事务改订单+库存+积分
  → 破坏一致性边界，回到分布式事务地狱
  → 跨聚合坚决用最终一致

错误 4：直接暴露内部集合
  public List<OrderItem> Items { get; } → 外部 order.Items.Clear() 绕过规则
  → 返回 IReadOnlyCollection，或私有 + 显式方法

错误 5：按表建聚合/仓储
  OrderItem 单独建仓储 → 它不独立，违反"整体存取"
  → 仓储按聚合根建