[TYPO3-50-general] FLOW3 Sample Blog Application Aggregate Roots Clarification

[Nino Martincevic]

Hi Duo!

First of all:
A problem of DDD is the lack of (good) examples. But that's not the 
problem of people being too lazy to provide some but it's that DDD is 
best suited for complex domains.
Therefore it's not that easy to give simple examples of complex things 
without losing the context and creating confusion.

Another hard point is: DDD is a mindest, not a technology (or at least a 
collection of useful "patterns"). Even if you provide an example it may 
be plain wrong in another domain or scenario.

Also let me say, I don't wanted to blame the Blog example or the Flow3 
team for providing such an example. As said above, it's not that easy.

I just updated that example and if you take a look at all the classes in 
the Model folder you cannot see any behaviour in them, just getters and 
setters. But domain models are all about behaviour. If you don't have 
it, take an ORM. It gives you all the power you need for such (anaemic) 
models.

Duo Zheng wrote:
>> An object being part of an AR in one case and the AR itself in another
>> is pure valid and clean
> 
> Can you provide an example of this? I would like to clearly see a case  
> when it is valid.

One of the hardest things is to NOT see Aggregates as relations but as 
logical units, a "whole thing" for a specific problem.

Two "facts" about ARs one cannot repeat too often:
Aggregates are not static, it may be intuitive but it's plain wrong.
ARs depend on the use case.

Instead of having ARs like Customer, Order or Shop think in terms like 
Registration, Buying, Delivery or Invoicing.

Then it becomes clearer that e.g. an Order or a Customer in one BC may 
be is just an association or even only an ID and in another context it 
is the AR of that context. All of the four example BCs may deal with the 
entity Order.

A very simplified trivial example:

BC 1 "Shopping":

class Cart { // AR
   var $lineItems; // List
}

class LineItems { // AR
   var $lineItems; // List
}

Both are ARs, because I want to modify them independently.

BC 2 Ordering:

class Order implements IAggregateRoot {
   var $lineItems; // List
}

Only Order is an AR, because here the lineItems simply don't make sense 
without an Order and I don't have to modify them.


> If Blog is a Root then it should be responsible for Post. If Post is  
> also a Root then it seems Blog has just delegated the responsibility  
> to another Root disguised as only an Entity in that specific case? It  
> does seem like unclear and undefined boundaries.
> 

It's ok for both to have its own Repository because you could modify 
them separately in different contexts.
But as said above you should stay in that context and play only with the 
actors that know their neighbourhood.
The Law of Demeter my be of great help when playing with modelling and 
trying to find violations.

Hope that helps.

Cheers!
Nino