Nesting of multiple Entities / AggregateRoots?

[seekM]

I tried to model a domain using jmolecules and trying to nest multiple Entities resp. AggregateRoots lead me to compilation errors:

---

Entities example:

public class Foo implements AggregateRoot<Foo, FooId> { ... }
public class Bar implements Entity<Foo, BarId> { ... }
public class Woo implements Entity<Bar, WooId> { ... } // (1)

For (1) I get:

Bound mismatch: The type Bar is not a valid substitute for the bounded parameter <T extends AggregateRoot<T,?>> of the type Entity<T,ID>

---

AggregateRoots example:

public class Foo implements AggregateRoot<Foo, FooId> { ... }
public class Bar implements Entity<Foo, BarId>, AggregateRoot<Bar, BarId> { ... }  // (2)
public class Woo implements Entity<Bar, WooId> { ... }

For (2) I get:

The interface Entity cannot be implemented more than once with different arguments: Entity<Bar,Bar.BarId> and Entity<Foo,Bar.BarId>

---

I am wondering if I am doing something wrong in this regard, if this kind of modelling is something which is not allowed / recommended in DDD and hasn't been implemented because of that or if this is maybe something which could be implemented in the future?

If I'm not mistaken the AggregateRoots example could work if Foo referred to Bar by Bar's ID; in this way Bar wouldn't be part of the Foo Aggregate. However, it feels to me that in the Bounded Context I am modelling it doesn't make a lot of sense for Bar to be able to exist without Foo, so I went for the approach shown here (Foo having a direct reference to Bar). I'm happy to share a bit more about the domain I am modelling if this is helpful.

[odrotbohm]

An entity is owned by one aggregate root, as otherwise, the aggregate cannot fulfil its constraining nature. That's is why you declaration of Bar works. Woo is wrong as you need to point it to an owning aggregate, which you don't as Bar is none.

From what you write, it feels like Bar should be its own aggregate and Foo simply refer to it via its identifier or an Association.

[seekM]

Thank you for your response!

I adjusted Woo also pointing to Foo as its owning Aggregate. But that also means that only Foo can have fields of type Woo, doesn't it? I.e it's not possible to nest Entities within one Aggregate, is it? (I tried to have Bar have a field of type Woo, but the JMoleculesDddRules complained: Field c.e.s.g.Bar.woo is of type Woo and declared to be used from aggregate Foo!)

Is there a reason that this restriction is in place, if I may ask? I read the blue book and partially the red book and can't remember that it was stated there that it's not recommended to have more than two levels of entities within one Aggregate (including the Aggregate Root). The red book gives an example of an Aggregate which consists of three levels of Entities at page 356 (figure 10.3). Admittedly, it is given as an example for a large-cluster Aggregate which won't scale well, but it's not said that this shouldn't be possible in general; it's only stated that an Aggregate should be as small as necessary.

To give a more concrete example: I'm modelling a Scrabble-like board game. The Game Bounded Context comprises game logic only. Here, a Game consists of Players and a Board. A Board consists of multiple Rows. A Row consists of multiple Fields on which Tokens can be placed. Each Player has a set of Tokens. I thought of Game to be an Aggregate Root, because its placeTokenOnBoard(...) -method/interface ensures that a player can only place Tokens on the Board which they are in posession of. I thought of Board, Row and Field to be Entities because they all have a lifecycle throughout the Game (Tokens can be placed on them). I was thinking that it doesn't make much sense for Board to be its own aggregate that is referred to from Game by its identifier or an Association , because a Board can only be interacted with through the Game interface (because Game has to protect the invariants). That's why I am thinking that Board, Row and Field should be part of the Game Aggregate; structured hierarchically as stated above. I was also wondering if Board, Row, and Field couldn't be Value Objects instead, but this somehow doesn't feel as natural to me... that's the backstory for my request, thank you for reading!