基本综合问题

Question

是否允许客户端代码引用非根聚合中的实体？我有一个Story（根）、Team（实体）和TeamMember（实体）。我试图确定 AddTeamMember 方法是否属于 Team 或 Story。

我想我的例子有点误导。我真正的问题是客户端代码可以引用聚合中的非根实体吗？

Answer 1

我的意见 - 不应该。引用属于某个聚合的实体意味着您可以在没有完整聚合上下文的情况下调用该实体上的方法，如果您允许这样做，您将永远无法确定整个聚合是否有效且一致。

简单的示例：

    public class MyAggregateRoot
    {
        protected MyEntity entity;

        public void BuildUpAggregate()
        {
            ValidateSomeRule();
            LoadEntityFromDatabase();
        }

        public MyEntity MyEntity
        {
            get 
            {
                VerifySomeOtherRule();
                return entity; 
            }
        }
    }

如您所见，在通过聚合根构建和检索 MyEntity 时，我们检查了两个验证规则 - 如果您允许客户端直接引用 MyEntity，则聚合可能会在客户端检索实体和执行操作之间的时间发生变化它，因此支票将不再有效，但您甚至不会意识到这一事实。换句话说，您的聚合将不一致并且可能无效。

一般来说，在 DDD 中有一条强有力的规则，规定对聚合中的实体的所有访问都应该通过从聚合根开始遍历来执行——这条规则正是为了聚合的一致性。

也就是说，您的客户端可以引用的是实体的投影 - 一种只读副本，其中仅包含显示和决定特定操作在当前上下文中是否可用所需的数据。您可以更进一步，将一组实体中的数据聚合到单个投影中，稍微调整一下，以便根据 UI 的要求进行定制。我发现这种技术非常有用，因为它不允许我的 UI 决定如何对业务领域进行建模。

Answer 2

在不知道您的架构应该如何工作的情况下，听起来它应该在Team而不是Story上进行。假设您有一个从 Team 到 Team Member 的一对多关系，并且 Team Member 是 Team 的子级code> 对象，而不是 Story。

Answer 3

我不确定“根”或“聚合”规则，但我认为故事不应该知道如何管理团队成员资格。

Answer 4

团队应该与团队成员有“有”关系。其中故事和团队成员彼此没有直接关系。

你的类应该如下所示：

class team
{
list<TeamMember> teamMembers;
void AddTeamMember(TeamMember member){}
}

团队必须有添加团队成员方法的另一个原因，如果该方法是故事的一部分，那么你必须明确提及你想要在哪个团队中添加成员。

addteamMember(Team T, TeamMember member);

根应该提供正确的方法来访问非根元素（第一层嵌套）。在您的情况下，团队应该有 addTeamMember 方法，而故事应该有一个方法 (AddMemberToTeam(team t, teammember m)) 调用指定团队的 addTeamMember 方法。