For contributing to this debate just referencing external sources:
There seems to be a "little" debate about "referencing ids vs lazy loading (with or without "direct" reference)" and more on the DDD Yahoo User group... http://tech.groups.yahoo.com/group/domaindrivendesign/message/24048 The main point is that sometimes this "Domain Id." does not correspond to any Domain concept, so it shouldn't be introduced on the Domain model. Also, there's an interesting blog post about this 2 ways of implementing DDD: http://rogeralsing.com/2009/11/08/two-flavors-of-ddd/ But I simply would notice that both approaches can be mixed (specially on different Bounded Contexts). If one BC is implemented over a framework that supports by default "lazy loading" a direct reference will be exactly the same in size as a "referencing id" and none of the problems noticed on Vaughn's "Implementing DDD" would occurred. During my evaluation, I think the following assumptions can be made about the Apache Isis default programming model (please, correct me if any of them is incorrect or if there are any additional points to consider): - By default all referenced objects are lazy-loaded. - Wicket viewer only implicitly loads a referenced object for showing it's name. For the referenced object only it's name will be loaded, so this will break the "loading chain" (no other referenced objects, are they will also be lazy-loaded, unless explicitely told; nor the name of this dependent objects). - Updating collections will not cause JDO/DataNucleus to update the version on the Aggregate Root / PersistenceCapable Entity. - Collections are "disabled" (lazy-loaded) by default, unless explicitely annotated, by the Apache Isis "contract" with the programmers and implemented viewers. If they must be eagerly loaded, the programmer must explicit it by annotating the Collection with @Resolve(Type.EAGERLY), such as in: public class Order { @Resolve(Type.EAGERLY) public List<LineItem> getLines() { ... } ... } - Same happens for direct Entity references: public class Order { @Resolve(Type.EAGERLY) private Customer customer; ... } Cheers, Oscar El 19/04/2013, a las 15:37, Dan Haywood <[email protected]> escribió: > 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 >>> >>> >>>
