无数据库访问时，如何从子实体获取父实体/聚合根信息？

核心思路：传递上下文而非依赖实体关联 #

既然无法访问数据库，且子实体不能直接持有无关属性或复杂根关联，核心应该是在请求处理链路中提前组装通知所需的上下文，而不是让子实体自己去“找”父/根信息。

方案1：使用领域事件携带上下文 #

在聚合根或父实体的操作过程中，当需要触发通知时，直接构造包含所需根/父信息的领域事件，然后将该事件传递给通知模块。子实体只需要触发事件，不需要关心事件里的额外信息——因为事件是在能访问根/父实体的层级创建的。

示例（.Net简化代码）：

// 在聚合根层级定义事件
public class OrderShippedEvent
{
    public Guid OrderId { get; }
    public string CustomerName { get; } // 根实体的通知所需信息
    public ShipmentItem Item { get; } // 子实体

    public OrderShippedEvent(Guid orderId, string customerName, ShipmentItem item)
    {
        OrderId = orderId;
        CustomerName = customerName;
        Item = item;
    }
}

// 子实体中触发事件
public void MarkItemShipped()
{
    // 状态变更逻辑...
    DomainEventPublisher.Publish(new OrderShippedEvent(
        _orderId, // 子实体仅持有根ID
        _customerName, // 初始化时从根注入的上下文字段
        this
    ));
}

这里子实体只需要持有根的ID和必要的最小上下文字段，这些字段在聚合根初始化或操作时就注入给子实体，避免后续查询。

方案2：引入通知上下文对象 #

创建专门的NotificationContext类，在请求进入时，从已加载的聚合根中提取所有可能用于通知的信息，将上下文对象在处理链路中传递。当通知模块需要处理子实体时，直接从上下文对象中获取所需的根/父信息，不需要子实体自己存储或查找。

• 优点：上下文是一次性组装的，避免重复数据，也不会污染实体的核心属性。
• 注意：上下文要按需组装，只包含通知所需的字段，避免过度封装。

方案3：优化实体的关联设计（有限关联） #

如果子实体确实需要关联根，但不想做大量类型检查，可以定义一个通用的IAggregateRootReference接口，让所有聚合根实现该接口，子实体持有这个接口类型的引用，而非具体的根类型。这样子实体可以通过接口获取通用的根信息（比如ID、通用标识字段），如果需要特定字段，可以用模式匹配（.Net 8+支持更简洁的语法）。

示例：

public interface IAggregateRootReference
{
    Guid Id { get; }
    string NotificationKey { get; } // 通用的通知所需字段
}

// 具体聚合根实现接口
public class Order : IAggregateRootReference
{
    public Guid Id { get; }
    public string NotificationKey => $"ORDER_{Id}";
    public string CustomerName { get; }
}

// 子实体持有接口引用
public class ShipmentItem
{
    private readonly IAggregateRootReference _root;

    public ShipmentItem(IAggregateRootReference root)
    {
        _root = root;
    }

    public void GenerateNotification()
    {
        // 使用通用字段
        var rootKey = _root.NotificationKey;
        // 需要特定字段时用模式匹配
        if (_root is Order order)
        {
            var customerName = order.CustomerName;
            // 生成通知逻辑
        }
    }
}

这种方式避免了冗余的类型检查，同时保持实体的职责单一，只有真正需要特定根信息时才做匹配。

对原有方案的优化补充 #

• 针对“实体添加额外信息”：可以改为仅添加通知所需的最小字段，而非整个根实体，并且明确标注这些字段是用于通知上下文的，避免属性污染。
• 针对“内存缓存”：如果必须用缓存，可以采用请求级缓存（比如用AsyncLocal存储当前请求的聚合根信息），这样不会有并发瓶颈，也不会出现缓存未命中——因为每个请求的聚合根已经被加载。

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