Aggregates and Foreign Keys

[Wouter Blancquaert]

Hi guys,

I've been crawling this forum to find a reasonable explanation but failed doing so (might also because my query skills suck, in that case forgive me).

We're having an internal discussion here about aggregate roots and the usage of foreign keys.

Basically, what I understood is that aggregates are designed according to your transactional requirements.

Assuming:

- we have an aggregate A and another aggregate B

- assume A and B share a 1 to many relationship.

- B refers to A by using it's identifier (so not the full object) because of the aggregate / eventual consistency definition.

- We use an RDBMS to store A and B where each have their own table

- B has a column referring to an identifier A.

My big question is: Is it wise to put a FK constraint in the RDBMS between B and A? It feels like breaking the aggregate / eventual consistency rule. But what I really want to know is what the problem would be if we would introduce the FK in the database. Or am I completely mishitting the ball and is that FK allowed and even preferred.

Thanks!

[Boris Guéry]

Whenever I read Aggregate and later RDMS I throw up the red flag.

Be careful (no offenses here) with the meaning of the words in a specific context.

The transactionality of your aggregates is something somewhat different to the one in an RDBMS (even if they intend to solve a similar problem).

You do not have to think about your persistence when designing your aggregate, but the reverse is also true, you should not really think of your aggregate when setting up your persistence.

Nothing prevent you to set up FK in your favorite RDBMS to prevent inconsistent storage of your data. 

I wouldn't use it to enforce my invariants though, but if it is the way your persistence works to ensure them, use it.

tl;dr;

Ensure you have an enough abstracted layer of persistence to enjoy your aggregates without having to care about how the data is persisted.

Use FK if it applies and if it makes sense for the consistency of your stored data.

--
Boris Guéry - IT Consultant / Software Architect

twitter: @borisguery
mobile:  +33686830312
skype:   borisguery

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.

[Danil Suits]

Is it wise to put a FK constraint in the RDBMS between B and A? It feels like breaking the aggregate / eventual consistency rule. But what I really want to know is what the problem would be if we would introduce the FK in the database. Or am I completely mishitting the ball and is that FK allowed and even preferred. 

 
If the RDBMS is your book of record, then adding a foreign key constraint introduces an invariant that your model isn't aware of.  One of the nice things in aggregates is that you get all of the invariant enforcement in one place, and the provider requirements of your persistence solution can be made explicit in your service provider interfaces.

In my mind, foreign key constraint is effectively a form of set-validation ( http://codebetter.com/gregyoung/2010/08/12/eventual-consistency-and-set-validation/ ).  RDBMS is really good at set validation, so why not? -- it's not free, but the costs aren't obviously high -- not until the foreign key hits end of life.  If you remove aggregates from the RDBMS when they reach the end of their lifetime, then I wouldn't introduce the foreign key without a compelling cost analysis.

If the RDBMS is not the book of record (the tables have views of the aggregates, rather than the aggregates themselves), then you've got a separate set of concerns, I think.  I'd probably be inclined to leave it out -- I would expect updating views to be considerably simpler without needing to worry about the validity of the foreign keys.

[Boris Guéry]

On Wed, Jan 18, 2017 at 5:48 PM, Danil Suits <danil...@gmail.com> wrote:

If the RDBMS is your book of record, then adding a foreign key constraint introduces an invariant that your model isn't aware of.  One of the nice things in aggregates is that you get all of the invariant enforcement in one place, and the provider requirements of your persistence solution can be made explicit in your service provider interfaces.

 

Absolutely agree on this point.

 

In my mind, foreign key constraint is effectively a form of set-validation ( http://codebetter.com/gregyoung/2010/08/12/eventual-consistency-and-set-validation/ ).  RDBMS is really good at set validation, so why not? -- it's not free, but the costs aren't obviously high -- not until the foreign key hits end of life.  If you remove aggregates from the RDBMS when they reach the end of their lifetime, then I wouldn't introduce the foreign key without a compelling cost analysis.

Agreed too, though, as I said, nothing prevent the usage of FKs, that's a feature of the persistence, the key is to keep it on the persistence layer.

I sometimes find it useful during the development as it may warn you of incorrectly persisted data, or help to browse the database through relationship.