0

We are developing an application based on DDD principles. We have encountered a couple of problems so far that we can't answer nor can we find the answers on the Internet.

Our application is intended to be a cloud application for multiple companies.

One of the demands is that there are no physical deletions from the database. We make only passive deletion by setting Active property of entities to false. That takes care of Select, Insert and Delete operations, but we don't know how to handle update operations.

Update means changing values of properties, but also means that past values are deleted and there are many reasons that we don't want that. One of the primary reason is for Accounting purposes.

If we make all update statements as "Archive old values" and then "Create new values" we would have a great number of duplicate values. For eg., Company has Branches, and Company is the Aggregate Root for Branches. If I change Companies phone number, that would mean I have to archive old company and all of its branches and create completely new company with branches just for one property. This may be a good idea at first, but over time there will be many values which can clog up the database. Phone is maybe an irrelevant property, but changing the Address (if street name has changed, but company is still in the same physical location) is a far more serious problem.

Currently we are using ASP.NET MVC with EF CF for repository, but one of the demands is that we are able to easily switch, or add, another technology like WPF or WCF. Currently we are using Automapper to map DTO's to Domain entities and vice versa and DTO's are primary source for views, ie. we have no view models. Application is layered according to DDD principle, and mapping occurs in Service Layer.

Another demand is that we musn't create a initial entity in database and then fill the values, but an entire aggregate should be stored as a whole.

Any comments or suggestions are appreciated. We also welcome any changes in demands (as this is an internal project, and not for a customer) and architecture, but only if it's absolutely neccessary.

Thank you.

civan
  • 254
  • 3
  • 9
  • Why does technology need to be pluggable? Pick one and stick to it. You're not doing DDD while you're figuring out how to make infrastructure pluggable. You could pick event sourcing for this one aggregate and not for others, or you could deal with temporal patterns for storing data. Depends on how comfortable you are with them and how much friction (in case of temporal patterns) it's causing. – Yves Reynhout Mar 03 '12 at 09:53

2 Answers2

2

Have you ever come across event sourcing? Sounds like it could be of use if you're interested in tracking the complete history of aggregates.

David Masters
  • 8,069
  • 2
  • 44
  • 75
  • I've never come across this interesting! Thanks – Sparkle Mar 01 '12 at 21:41
  • Honestly, I never heard of it. I'm in process of reading Martin's article on it. Could you recommend some other examples (in .NET if possible) other than Martin's? Or maybe, could you give an example on the problem I wrote considering Companies and Branches? – civan Mar 04 '12 at 08:39
  • Event sourcing forms part of CQRS - there is a whole bunch of links here: http://stackoverflow.com/questions/5043513/cqrs-examples-and-screencasts – David Masters Mar 04 '12 at 09:31
  • If you structured your app with event sourcing, you'd be able to view the history of your company agg, seeing a list of events that have occurred in its lifetime. So could see "[Date] [EventName] [Old Value] [New Value] [UserWhoChanged]". To be honest though, this is no quick solution and a major change in structure. Really, you need to change to a task based UI in order to capture the user's intent to produce the events. Perhaps the separate tables is your best option if your project is already in dev. However, the possibilities that event sourcing (& CQRS) brings really makes it considering. – David Masters Mar 04 '12 at 09:46
  • I have to accept Sparkle's answer as we lack knowledge about event sourcing and time is short, but thank you for pointing out event sourcing. Maybe in future apps... – civan Mar 04 '12 at 16:51
0

To be honest I would create another table that would be a change log inserting the old record and deleted records etc etc into it before updating the live data. Yes you are creating a lot of records but you are abstracting this data from live records and keeping this data as lean as possible.

Also when it comes to clean up and backup you have your live date and your changed / delete data and you can routinely back up and trim your old changed / delete and reduced its size depending on how long you have agreed to keep changed / delete data live with the supplier or business you are working with.

I think this would be the best way to go as your core functionality will be working on a leaner dataset and I'm assuming your users wont be wanting to check revision and deletions of records all the time? So by separating the data you are accessing it when it is needed instead of all the time because everything is intermingled.

Sparkle
  • 2,459
  • 3
  • 18
  • 20
  • This is something that one of our team members had in mind. We're definitely going to consider this alternative as well as event sourcing. – civan Mar 04 '12 at 08:36
  • I will accept your answer as the one we need because we don't have enough knowledge about event sourcing, but your idea is quite good and is something that we were thinking of. – civan Mar 04 '12 at 16:49