Domanda

I am almost certain I have overlooked something simple, but it hasn't clicked.

I have a Person entity (root of Person aggregate). I also have a child entity for Authentication and Authorization (Auth) which has List of Roles and List of Permissions.

I want modifications to Roles and Permissions to be managed through the root, using AddAuthRole, etc. methods on the root.

This is fairly straightforward, but how would I go about doing this while not exposing any similar functionality in the Auth entity? I do not want consumers using a ref to the child to try to Add and Remove against these lists.

I have a feeling that this is some basic OO concept that I should be ashamed to be unaware of...

È stato utile?

Soluzione

Restricting access to members of an Aggregate is IMO more a matter of convention than strict enforcement. I don't believe in "physical" boundaries you could place around an Aggregate, they are way too restrictive and unnecessarily complicated. See DDD / Aggregates in .NET

I don't quite get the design of the classes in your example, but if Authentication and Authorization are members of the Person Aggregate and you want to protect them, just don't reference them from the outside. This is just a basic DDD convention that every programmer on your team should care about -no cross-Aggregate references except ones that point directly to Aggregate Roots.

The need for access restriction and protection of your domain objects will also be drastically reduced if you're using immutable value objects. Roles and Permissions could typically be such value objects, allowing you to expose them to the world without the risk of external objects fiddling with their state and modifying them. Because that's what Aggregates are for in the first place : gathering all manipulation rules of some entities in a single place to prevent anyone from fiddling with these entities.

Altri suggerimenti

If you expose you lists via a more restrictive interface, IEnumerable maybe, you'll be able to control how users of your aggregate access them. Your lists exposed via IEnumerable, combined with add/remove methods on the root should give you what, I've interpreted, you want.

exposed methods should be protected all others should be private

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top