1

我正在开发一个 CMS 类型的应用程序，并希望使用一些 ddd 战术模式。情况如下：

该应用程序处理项目的创作和发布。

项目在工作流组中组合在一起。在该组中，一个项目可以标记为“已发布”，一个项目可以标记为“工作中”，任何数字都可以标记为“存档”。

只有处于“工作”状态的项目才能被编辑。

发布工作项目时，它会替换其相应的已发布项目（如果有），然后将其标记为已存档。

如果不存在草稿，则可以通过复制已发布版本或任何存档版本来创建新的工作版本。

问题是，按照聚合应该封装系统不变量的指导，工作流组是否应该是聚合根 - 包含它的所有项目？

我担心这会产生相当大的聚合，并且会阻止项目在全球范围内可访问（即所有交互都必须通过 Workflow Group AR）。

我看到的另一种方法是使 Item 成为 Aggregate Root，然后让域服务处理事务和不变量。例如：

PublishWorkingItem(int itemId) 
{
    Item workingItem = itemRepo.GetWorkingItem(itemId);
    Guid groupId = workingItem.GroupId;
    Item publishedItem = itemRepo.GetPublishedItemForGroup(groupId);
    if(publishedItem != null) 
    {
        publisheditem.Archive();
    }
    workingItem.Publish();  
}
4

2 回答 2

3

AR应该有自己的生命周期。这是您应该能够从您的领域专家那里得到的东西。

AR 还在于在高度内聚的对象图周围具有锐利的边缘。

如果你发现你在另一个里面有一个 AR，你需要删除包含的 AR 并将其替换为仅包含的 ID 或值对象。

在您的情况下，例如，活动项目和存档项目之间可能存在差异，因此存档项目不是WorkflowAR 的一部分。但是您最终可能会制作ItemAR，在这种情况下，您的WorkflowAR 可能包含活动项目 ID/VO 的列表。

只是一些想法:)

于 2013-06-12T04:25:23.060 回答
3

If you haven't already, I strongly recommend reading vaughn vernon's series of articles about effective aggregate design. Part II suggests that you should consult with your domain expert on whether it may be accepted to have stale data in the system. If the answer is yes, you may consider having small aggregates (e.g. Item in your domain) that maintain eventual consistency rather than transactional. For example, this may mean that for some small amount of time, there may be two items with the published state, but eventually only one item will be published. You can achieve this kind of behavior using domain events. Having a large transactionally consisted aggregate is also an option, but it may result in high concurrency contention if many users attempt to manipulate the same group concurrently.

于 2013-06-11T20:52:20.390 回答