DDD：为实体及其状态创建存储库

Question

我的域中有一个实体，我需要跟踪它的状态。我有一个处理程序来满足这个需求。此状态类似于InProgress、Completed 或Deleted。我使用 CosmosDb、SQL API 来存储这些数据。

在 CosmosDb 中，我为这些创建的实体创建了一个容器，并为其状态创建了另一个容器。因此，在代码中，我为这两个容器创建了两个存储库。

internal interface EntityRepository
{
   Task AddAsync(Entity entity);
}

internal interface EntityStatusRepository
{
   Task AddAsync(EntityStatus entityStatus);
}

对于每个存储库，我都创建了一项服务

public interface EnityService
{
    Task AddAsync(Entity entity);
}

public interface EntityStatusService
{
   Task AddStatusAsync(EntityStatus entityStatus)
}

这些服务已公开为处理程序的公共接口，而不是存储库。

现在我真的很想知道

• 基于 DDD 并拥有一个实体及其状态，我应该创建两个独立的存储库还是应该将它们作为一个存储库，因为它们是一个上下文？

• 我是否需要通过一项服务公开实体及其状态？

不知道有没有人有建议甚至更好的解决方案？

Answer 1

看起来 EntityStatus 应该是 Entity 上的一个属性，但让我们通过逻辑来确定。请注意，这些不是硬性规则，只是我在做这些决定时的经验法则。情有可原的情况我取代了这些。

• EntityStatus 应该是聚合根吗？有意义吗 单独使用 EntityStatus 与任何事物无关 否则，还是只引用子对象？如果不是，那就是 不是聚合根。这意味着它要么是支持实体，要么是 属性。
• 如果父实体始终只有一个当前值 EntityStatus，并且不需要在状态中嵌入任何逻辑， 那么最好将其保留为实体上的属性。
• 如果 EntityStatus 需要内置逻辑，那么它可能应该 成为价值对象。例如，如果状态只能从 X 变为 Y 在某些情况下但不是在其他情况下，或者如果某些外部过程 必须在状态改变时启动，它应该是一个值对象 其值由实体设置。不过，作为一个值对象并不一定意味着它是一个单独的实体。

最后，我更喜欢将我的存储库绑定到聚合根，即使 AR 拥有值对象也是如此。 AR 更新应该全部保存或不保存，跨存储库扩展数据库单个事务不太理想。如果您使用的是工作单元模式，那么 AR 更新应该是一个单元。我尝试为每个表创建一个单独的存储库，其中 AR 存储库使用单个表存储库，并且所有管道代码都感觉过于精细。在处理所有浮动的部分时，也很容易失去你试图完成的商业理念。但最终，没有任何规则来管理这一点，所以你认为是正确的就去做吧。

Answer 2

我不是 DDD 专家 - 只是阅读 Vernon 的 Implementing DDD 但根据我的经验，您对 bounded context 有疑问。您的模型Entity 和EntityStatus 可能密切相关。在这种情况下，只有当您有一个需要 EntityStatuses 的地方时，您才应该创建 EntityStatusRepository。如果您同时需要它们，请使用EntityRepository