Re: Why can't each Aggregate Root have its own collections of entities/ARs?

I understand the motivation of Vernon of choosing the disconnected implementation, but I whole heartily agree with your statements that the natural usage of the domain model is getting impaired. In my insight Vernon chooses this approach to allow dynamic scaling from simple DB to distributed storage like Cassandra, by implementing the model already suited for distributed storage. Personally I feel not many systems will ever need that level of storage, so I'm inclined to keep my model more "sane". The same goes for the amount of usage of events; inter-domain, yes. Intra-domain; not if I can avoid it.

Tom



On 2013-08-27 04:57, jorgedfbranco wrote:
> Consider the following context:
>
> A World(Entity) has Continents. A Continent(Entity) has Countries. A Country has Cities(Entity). Let's for the sake of argument assume there are invariants involved for each one of the referred entities. As such, they are not only entities but ARs as well.
>
> Were I asked in a standard OO course to implement the classes that model the shown text, and I'd write the following:
>
>     class World {
>       String name; //identifies this entity globally
>       Set<Continent> continents = new Set<Continent>();
>       ...
>     }
>
>     class Continent {
>       String name; //identifies the continent uniquely in a world context
>       Set<Country> countries = new Set<Country>();
>       ...
>     }
>
>     etc
>
>
> Using this code is as simple as
>
>     Continent europe = new Continent("Europe");
>     europe.addCountry(new Country("Germany"));
>     europe.addCountry(new Country("Poland"));
>     World world = new World("Earth");
>     world.addContinent(europe);
>
>
> Now, from what I've gathered from Eric's and Vernon's book, though, is that I should replace this kind of design by one in which instead of having each Entity class have its own collections of child entities, to have a Repository by Aggregate Root type. I'd then have something of the like of
>
>     class World {
>       String name; //identifier globally
>       Set<ContinentId> continents = new Set<ContinentId>(); //ContinentId is a wrapper of a string
>       ...
>     }
>
>     class ContinentRepository {
>       ...
>     }
>
>     etc
>
>
> This IMO raises a couple of issues:
>
>  1. It obscures the code.
>  2. Entities transversion stops being possible without using an outside class (that, or each Entity must either have repositories injected or have its much needed repositories set as static singletons). That outside class may either be a Repository or a Domain Service.
>  3. Something as simple as adding a Country to a Continent will now need a Domain Service or a Repository, as Continent doesn't have what it takes to do the task at hand.
>  4. Shouldn't we strive for a architecture-neutral domain implementation? Just looking at these centralized repositories (instead of one collection by each entity object instan ce at runtime) makes me thing of a database-oriented application.
>
> When first reading about DDD's repositories, I got the impression they would be nothing more than an abstraction of a collection. But from what I gather from the examples abounding on the web and on Vernon's book, they sure seem more like an abstraction of a *singleton* collection. I call them singleton collections because in reality there is only one per type on a given system (there's always only a CountryRepository in memory! Only a ContinentRepository in memory!).
>
> I'm at the moment quite confused on the matter. It almost seems as all the examples I see regarding DDD are database(sql/nosql)-oriented , which is acceptable as that is the norm, but some of us work on "purer" grounds where no database is involved. What is really the problem with my initial bit of code?
>