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

Hi,

in my experience, and I am open to comment and critics, I would say:


  1.  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.
Read model is there to help you, well... read models are there to help in this case.

  1.  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.
using( var universe = repositoryFactory.BigBang() )
{
    var world = worldFactory.CreateNewWorld();
    var continent = continentsFactory.CreateContinent();
    world.AddContinent( continent.ContinentId );

    universe.Store( world );
    universe.Store( continent );
    universe.CommitChanges() );  //here the universe raises events that allows the creation of the read model
}

It's C# and is just a sample, but should give you the idea of what's going on.

Comments? Am I missing something?
.m


From: [email protected] [mailto:[email protected]] On Behalf Of jorgedfbranco
Sent: martedì 27 agosto 2013 04.57
To: [email protected]
Subject: [domaindrivendesign] Why can't each Aggregate Root have its own collections of entities/ARs?




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?