http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660I think that quite often, very deep object graphs have aggregates trying to get out. In the example above, we have order that contains shipments, but we can also see a shipment as a standalone aggregate. http://ayende.com/2356/aggregates-and-domain-validation#comment5http://ayende.com/2356/aggregates-and-domain-validation#comment5Thu, 03 May 2007 14:02:01 GMTNice stuff! Am I following you if I say that you propose, in your northwind example, that the only way to change anything inside the Order aggregate would be to call something like... myOrder.Modify(myChangeImpl); no matter if the application runs in a SOA/distributed enviroment or not? I mean - you don't have any public setters at all inside the aggregate? None at all, whatsoever (as far as they can break a business rule)? It's quite appealing in that sense, as you write, that business rules turns fully into a domain problem instead of a techinical problem. And the problem to do coarse grained optimistic locks I've fought with quite a lot recently turns a lot easier using this approach. However - and I'm not sure I agree to myself here - won't it be quite messy after a while? In a deep graph where every entity belongs to the same aggregate, there will be numerous different ways to change this aggregate as I see it. Or is it maybe just because I haven't really used this approach before? Maybe I just don't see the consequences fully? http://ayende.com/2356/aggregates-and-domain-validation#comment4http://ayende.com/2356/aggregates-and-domain-validation#comment4Thu, 03 May 2007 13:22:05 GMTAs I said, I don't like this approach, mainly because I gave an example where this is something that I want to break, so it is not an invariant, only validation for moving the order to processed state. I can't claim that I am very good at DDD, the last system that I wrote which had an opportunity for a good domain model got gnarly in the UI, and my current projects doesn't have much of a domain model in them (not much point). http://ayende.com/2356/aggregates-and-domain-validation#comment3http://ayende.com/2356/aggregates-and-domain-validation#comment3Thu, 03 May 2007 04:00:48 GMTYou really like this example? Assuming that your AddLine belongs to the Order domain, it's accessing a service (??!). In a true domain driven design you'd use a policy (or even a specification) to encapsulate and be more expressive about this rule. Also, in the light of ubiquitous language, there's a distinction between validation and invariants. You're enforcing invariants. http://ayende.com/2356/aggregates-and-domain-validation#comment2http://ayende.com/2356/aggregates-and-domain-validation#comment2Wed, 02 May 2007 23:46:54 GMTChange of state and bussines rule validation...we can encapsulate this into a workflow. http://ayende.com/2356/aggregates-and-domain-validation#comment1http://ayende.com/2356/aggregates-and-domain-validation#comment1Wed, 02 May 2007 22:30:43 GMT