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

I think you probably need to think more about the behaviour of the system.
You have described a data model that is a representation of the actual
world, but does that actually support the behaviour you would like the
system to display/implement? Once you have created the web of objects as
described, what do you actually want to do with it?

You have said "when asked in a standard OO course..." you'd write it that
way. Taking that existing model that was designed that way, changing the
object references to identity references and starting to talk about
repositories is not really what DDD is about. I think what you probably
need to do is throw away completely that initial model and start again, it
is probably the thing that is causing you the most confusion.


/*
Email: [email protected]
Twitter: @simonmfox
*/


On 27 August 2013 14:57, jorgedfbranco <[email protected]> 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 instance 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?
>
>  
>