我几乎可以肯定我忽略了一些简单的事情,但它没有点击。
我有一个 Person 实体(Person 聚合的根)。我还有一个用于身份验证和授权 (Auth) 的子实体,它具有角色列表和权限列表。
我希望通过根管理对角色和权限的修改,在根上使用 AddAuthRole 等方法。
这相当简单,但是我将如何在不暴露 Auth 实体中的任何类似功能的情况下执行此操作?我不希望消费者使用孩子的参考来尝试添加和删除这些列表。
我有一种感觉,这是一些基本的 OO 概念,我应该为不知道而感到羞耻......
我几乎可以肯定我忽略了一些简单的事情,但它没有点击。
我有一个 Person 实体(Person 聚合的根)。我还有一个用于身份验证和授权 (Auth) 的子实体,它具有角色列表和权限列表。
我希望通过根管理对角色和权限的修改,在根上使用 AddAuthRole 等方法。
这相当简单,但是我将如何在不暴露 Auth 实体中的任何类似功能的情况下执行此操作?我不希望消费者使用孩子的参考来尝试添加和删除这些列表。
我有一种感觉,这是一些基本的 OO 概念,我应该为不知道而感到羞耻......
限制对聚合成员的访问是 IMO 更多的惯例问题,而不是严格执行。我不相信您可以在聚合周围设置“物理”边界,它们过于严格且不必要地复杂。请参阅.NET 中的 DDD / 聚合
我不太了解您示例中的类的设计,但是如果身份验证和授权是 Person Aggregate 的成员并且您想保护它们,请不要从外部引用它们。这只是一个基本的 DDD 约定,您团队中的每个程序员都应该关心 - 没有跨聚合引用,除了直接指向聚合根的引用。
如果您使用不可变值对象,则对域对象的访问限制和保护的需求也将大大减少。角色和权限通常可以是这样的值对象,允许您将它们公开给世界,而不会有外部对象摆弄它们的状态和修改它们的风险。因为这就是聚合首先要做的:将某些实体的所有操作规则收集在一个地方,以防止任何人摆弄这些实体。
如果您通过更严格的界面(IEnumerable)公开您的列表,您将能够控制您的聚合用户如何访问它们。您通过 IEnumerable 公开的列表与根目录上的添加/删除方法相结合,应该可以为您提供我解释过的您想要的内容。
暴露的方法应该受到保护所有其他的应该是私有的