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

[Duo Zheng]

Nino,
Thank you so much for taking the time to explain that!!! Your  
explanation was simply awesome. Thanks Thanks Thanks! I've been  
"thinking" in the wrong direction and also perhaps trying to apply the  
concepts where it is not as appropriate.

Robert Lemke just released a tutorial. I haven't read it yet, but am  
going to now. I think it contains some explanation on the Blog  
application. I am interested to see if that write up clarifies about  
the design choices made.

http://flow3.typo3.org/documentation/tutorials/getting-started/

Thanks Again,
Duo

On Aug 18, 2009, at 5:05 PM, Nino Martincevic wrote:

> 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
>
> _______________________________________________
> TYPO3-project-5_0-general mailing list
> TYPO3-project-5_0-general at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-project-5_0-general