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 > > > > 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 >> >>
