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

Mauro Servienti <[email protected]>
Newsgroups gmane.comp.programming.domain-driven-design
Message-ID <c13a11b22b7742429e6398032880485a@AMSPR03MB114.eurprd03.prod.outlook.com>
@Mauro:

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
}

My "distress" with the example is the major undertaking involved -- 3 factories -- bearing no clear advantage in the process (occam's razor). I may be missing something, though. Plus, as originally stated, the world in your example has continents -- their primary id, but to actually make something with them, for instance, to know how many continents a given world has, you'll need to *know* some outside class -- a repo, a domain service.

Getting the number of continents from a World object in my example would only require a simple

int numberOfContinents = world.numberOfContinents();

implemented as

public int numberOfContinents() {
  return continents.size();
}

I'm curious as of how you'd get the number of continents given a world instance. Would you put that logic in the ContinentRepository? In the WorldRepository? In a service? In the World class, passing a repository as argument?

[.m] Factories are there simply because I hate constructors, they are not mandatory at all, and in some cases, and maybe this is one of them, an AR can be a factory itself, maybe is sustainable that a continent is created by a world.

On the other side I have one single rule of thumb, learned some time ago from a dear friend and applied successfully in a lot of projects:

Aggregates can only have “void” methods, no public properties no return values, only methods with arguments and must raise events.

Given that rule it is an easy task to generate read models, o lot of read models per use case/scenario, with all the required information; the AR simply carries with itself only the information required to guarantee business rules, invariants and so on, but it is an AR problem that can change over time without breaking anything.

.m
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.