So, one last mail in this thread. I've not cc'ed Vaughn this time, so we won't get a reply (and I don't think he would want to anyway), but anyway...
The point that Vaughn makes about "allowing your consistency boundaries to change per use case" is interesting. And I remember Udi Dahan make this point a long time ago too [1]. According to this viewpoint, then each aggregate changes over time, rather than being statically defined across all time. That is, the use case starts with an interaction with one and only one domain object, and the consistency boundary is simply the domain objects that are enlisted within the transaction as a result of invoking that action. Isolation level 3 (serializable) takes care of any consistency issues across entites. So the easy way out of this argument is to say that Isis supports aggregates, according to the above definition. After all, in Isis any given interaction results in the invocation of an action on a single domain object. However, I'm pretty sure that this dynamic morphing of aggregate boundaries isn't what Evans intended when he wrote the pattern. Hmm, perhaps I should ask him. Enough already. Have to get on with some work, here.... Dan [1] http://tech.groups.yahoo.com/group/domaindrivendesign/message/11202 On 19 April 2013 13:29, Vaughn Vernon <[email protected]> wrote: > Your bias may be mostly due to not actually using the Aggregate pattern. > If you were truly using Aggregates to define transactional consistency > boundaries then reference by id would not be a problem. (Maybe you allow > your consistency boundaries to change per use case.) You don't have to use > Aggregates to benefit from DDD, but it's good to understand when you are > and are not using them. This is true whether or not you are using > relational databases or kv stores. There is no difference in applying > Aggregate in either case. > > I am sure I will not have more to add. > > Vaughn > On Apr 19, 2013 1:56 PM, "Dan Haywood" <[email protected]> > wrote: > >> Thanks for commenting on this, Vaughn. >> >> You are right it is the consensus view, because the consensus seems for >> some reason to focus on NoSQL and non-transactional databases. I remain >> confused by this; the vast majority of enterprise systems are built against >> RDBMS, and that will the case. >> >> I still haven't heard any good reason to follow your "disconnected domain >> model" if using an RDBMS. >> >> Actually, that's not quite right. Over in Ireland on the big Naked >> Objects system based on .NET and Entity Framework, we *do* use the pattern >> when entities in different EF DbContexts refer to each other. We have one >> DbContext for each module (namespace); eg Customer, Document, Security, >> Appointment, Task, RecordedAction, GenericScheme, Payment and so on. The >> modules form a DAG, preventing the domain model becoming a big ball of mud. >> EF cannot manage relationships between entities in different modules, >> and so we do it ourselves using a pattern that is basically equivalent to >> the "disconnected domain model". >> >> We also do this because we want polymorphic relationships between >> entities in different modules. For example, there are many objects in >> different modules that can act as a DocumentHolder. The Document module >> defines this as an interface, and each Document references its >> DocumentHolder, but the actual class that implements this interface could >> be in any of several modules. Even if we weren't using modules, we would >> need to do this because (at the moment) EF does not support polymorphic >> relationships. >> >> As I see it, if using an RDBMS, the notion of module is a much more >> important organizing concept than aggregate. But I find there's virtually >> no discussion of the module pattern by those that hold the "consensus view". >> >> Hope the above doesn't come over as a rant; but I do think that that >> article doesn't sufficiently explain why the disconnected domain model >> pattern should be "preferred" in all cases; bottom line: I don't think it >> should. >> >> Dan >> >> >>
