How to prove the consistency of aggregates in DDD (Technically)?

user_8618595 0
Viewed 691

Ensuring the consistency of our aggregate is so important thing when developing web applications using DDD.

I worked in the past on a web application(no DDD) where we tried to ensure the consistency of our data using Transactions.So, We used Serializable transaction level and it was a nightmare for our team because the performance of our application was so bad and a lot of deadlocks issues have been reported by our users.

Now I am working on a web application implementing DDD principles and I need to ensure the consistency of our aggregates.

I have read here http://geekswithblogs.net/Optikal/archive/2013/04/07/152643.aspx that optimistic concurrency/locking is one of the methods to achieve that throw assigning a version or timestamp to our aggregate to check against it.

My first question is how to achieve optimistic concurrency using C# and entity framework in conjunction with Sql Server including the whole process from the beginning to the end, and where to store that column/flag if we take order and line items example which Eric Evans gave it in his book?

My second question is what are the common strategies used to ensure aggregates consistency in case of race conditions?

I would appreciate any code snippet or references.

aggregateroot consistency domain-driven-design entity-framework c#
1 Answers

My first question is how to achieve optimistic concurrency using C# and entity framework in conjunction with Sql Server including the whole process from the beginning to the end, and where to store that column/flag if we take order and line items example which Eric Evans gave it in his book?

If you use a single table to store the entire Aggregate then you can use optimistic locking. For example you could use a JSON column to store the line items. For this case the document base NoSQL databases are a perfect fit.

If you use multiple tables (i.e. one table for the order and one table for the line-items) then I don't see how you could reliably use optimistic locking to ensure atomicity. In this case you need transactions.

My second question is what are the common strategies used to ensure aggregates consistency in case of race conditions?

You just retry the command. If you designed your Aggregate to be side effect free (at least to not make any IO calls) then this should not be a problem.

user_25752240
Related