CODEWITHSUNDEEP
c#sql-serverentity-frameworkdomain-driven-design
Ale
Ale

Reputation: 85

DDD: Referencing non root Entities by Id from other Aggregates?

We are implementing entities of a domain model in C# using Entity Framework for persistence.

A bit burned from past experiences, we are now trying to build small aggregates, referencing other roots by Id, as suggested among others by Vaugh Vernon in this article: http://www.informit.com/articles/article.aspx?p=2020371&seqNum=4

In some cases however, we feel we might be breaking rules by referencing, by Id, non root entities in other aggregates. As an example, imagine the model depicted below. See specifically the relation marked in red.

Obviously, since the relations are only "by Id" we do not break encapsulation of the SystemAttribute aggregate. I think this should be ok. The AttributeValueId can be defined as a Value Object, as suggested by Vernon et.al.

Now, if we feel it is ok to reference non root entities in this manner, we still have issues. To present a list of all AttributeValues of a given UserGroup (with the owning attributes of course) we need to perform "SELECT WHERE IN" based EF queries as opposed to just joining which would have been possible if using actual navigation property references. We could also use Raw SQL queries through the EF DBContext, taking advantage of the fact that we do have joinable FK-relations in the database.

Any ideas here or just an issue that needs to be judged whether acceptable or not?

I really like the idea of "soft references" between aggregates using Id's. But it seems to be not without issues.

Regarding the use of explicit entities for many-to-many relation tables in the DB and the decision not to make this a two-way relation - see these articles by Udi Dahan and Jimmy Bogard respectively:

https://lostechies.com/jimmybogard/2014/03/12/avoid-many-to-many-mappings-in-orms/

http://udidahan.com/2009/01/24/ddd-many-to-many-object-relational-mapping/

enter image description here

Upvotes: 2

Views: 1404

Answers (1)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57214

Any ideas here or just an issue that needs to be judged whether acceptable or not?

So the first idea that leaps to mind, is that you could satisfy the rule by moving the UserGroupAttributeValue table from the User Group aggregate to the System Attribute aggregate.

tomliversidge is asking the right question -- this arrangement looks primarily like structure; what are the rules governing change of state? Which consistency guarantees do you need to enforce with each change, and which can be resolved over some finite amount of time?

I'd add to this: are you sure you are doing in the right place? The usual place to do TDD is in your core domain (the place where your competitive advantage lies). Otherwise, you may be shopping in the wrong bin. (Note: that's more about at the strategic level, rather than down in the tactical implementation patterns).

Upvotes: 2

Related Questions