Good comment/point and you could be right about 4, I know it’s questionable and if we had 3 then it wouldn’t be an issue.

However if we don’t have 3 then I like the idea of switching off the UOW because otherwise I’m relying on convention to ensure that people validate aggregates before persistence or have to do some incredibly nasty workarounds to make that automatic (such as exceptions from interceptors or whatever).

On the aggregate validation angle, whilst I like the idea of having a repository behave like an in-memory collection doing so does make the aggregate invariants rule hard to apply:

“When a change to any object within the aggregate boundary is committed, all invariants of the whole aggregate must be specified”

If we follow this rule but also allow clients to update the aggregate piecemeal, rather than following Greg Young’s always valid approach, then committing does become an event that we are interested in. Unfortunately if the UOW takes care of it all for us and doesn’t give us a nice way to hook in then we’re left, primarily, with conventions.

I also find that the UOW is not a feature I find massively useful when working with DDD since I know which aggregates are being affected in a particular request. I thus don’t see losing it as being a big deal.

So yeah I agree with you in general and maybe I shouldn’t have added 4

Oh and Add/Remove, yeah I like that approach but these days most people seem to use freely available repository interfaces that tend to have Save/Update.

Ta,

Colin

Thought I would comment at your new home.

I agree with a lot of what you are saying (feeling your pain on 5 and 6)

I’m not sure that I agree with 4. My understanding of a repository is that it has collection semantics i.e. appears like an in-memory collection would.

With an in-memory collection I may add or remove items, but I don’t ever update them. With an in-memory collection I don’t have to re-add, just because I add a child to the parent that is already stored in the list.

Turning off unit-of-work would seem to me to break the collection semantics approach of a repository, because you now have to perform update operations. That means that the knowledge that I am using some sort of external persistent store bleeds into my domain model. I don’t really want that. I like what unit of work gives me in this regard, a lack of difference between in-memory and persistent storage.

I recently changed our repository base class to have an op named Add instead of Save because folks here got confused as to when they had to tell the ORM about their changes. If you use Add and Remove instead of Save and Delete its is a lot more obvious when you should use them.