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 On 19 April 2013 09:29, Vaughn Vernon <[email protected]> wrote: > Note the specific word "prefer" at the outset of the advice. > > This advice reflects the current consensus view among DDD leaders, but > there are reasons to break the rule(s) of thumb (RoT meaning, do this by > default but maybe not always). Also note the following this specific rule > in question could also lead to the need to use CQRS, and that this specific > rule in question is a good practice if working in a highly scalable > environment. > > As always we select one set of tradeoffs at the cost of others. What Dan > advocates has certainly been used over years by others, and to them for > very good reasons. > > Vaughn > >
