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

Hi Jorge

I am suggesting that solution if that is data (the number of countries per
continent) that the World AR uses to perform whatever it may be responsible
for. And no I'm not suggesting adding a map for each of the required pieces
of Continent data within World, if that starts happening then it is
probably an indication that your AR boundaries are wrong and you need to
re-evaluate your design.

Tom, I was not trying to optimize anything, I was simply trying to make the
point that there are other ways of modelling to the "nouns are entities,
verbs are behaviours" type mindset that in most cases will get you into the
exact problem we are talking about. The model looks anaemic and there are
relationships between entities for the sake of relationships, what value
are they adding in this case?

Cheers
Simon

/*
Email: [email protected]
Twitter: @simonmfox
*/


On 29 August 2013 20:06, Jorge Branco <[email protected]> wrote:

> **
>
>
> Hi again!
>
> Tom,
>
> Now if you take that further and say that a World needs to know how many
> Countries each Continent has to perform it's responsibilities, the only
> data that the World AR needs to hold is a map of ContinentID to Country
> count, again maintained via domain events.
>
>
>
> If I understood you correctly, you're favoring a solution along the lines
> of:
>
> class World {
>   Map<ContinentId, Integer> continentsSize = ...;
> }
>
>
> that from its inception on is updated via domain events. But if this is
> indeed the case, how would you deal with this if World needed also other
> things from continents other than size? Would you have a map for each one
> of the needed features?
>
> jorge
>
>
> On Thu, Aug 29, 2013 at 7:54 AM, Tom Eugelink <[email protected]> wrote:
>
>> **
>>
>>
>> Hi Dennis,
>>
>> Good question; neither I guess, I'm voicing an opinion.
>>
>> In an earlier post I said that I understand the reason for this
>> disconnected model, and I really do see the upside. I'm not closed minded,
>> but I also see the downside. And I'm really in doubt if the gain outweighs
>> the loss.
>>
>>
>>
>>
>>
>>
>> On 2013-08-29 08:41, Dennis Traub wrote:
>>
>>
>>
>> Tom,
>>
>> First off: Are you asking a question or trying to prove a point? You
>> responses to everyone trying to answer suggest the latter.
>>
>> That said, in my opinion Simon's answer was the first one in this thread
>> that really broke it down to what totally makes sense. And what he proposed
>> would radically simplify rather than complicate things. OO modelling is
>> best done with an open mind, not a pre-defined set of "that's how we did it
>> all the time"
>>
>> Best
>>
>> Dennis
>> On Aug 29, 2013 7:43 AM, "Tom Eugelink" <[email protected]> wrote:
>>
>>>
>>>
>>>  On 2013-08-29 00:03, Simon Fox wrote:
>>>
>>> Now if you take that further and say that a World needs to know how many
>>> Countries each Continent has to perform it's responsibilities, the only
>>> data that the World AR needs to hold is a map of ContinentID to Country
>>> count, again maintained via domain events.
>>>
>>>
>>> This of course is true, but it very much feels like "early
>>> optimalisation". I once knew a client (insurance company) who optimized its
>>> database for flexibility so far, that they ended up with two tables: one
>>> contained the datamodel, the other contained the values. Extremely
>>> flexible... Totally unusable, mainly because it performed awfully and
>>> newcomers had a very hard time getting date in and out of it.
>>>
>>> Now, I'm not comparing that situation with the current discussion
>>> directly, but it illustrates that there needs to be a balance between
>>> optimization (on what ever aspect) and usability. The disconnected nature
>>> of a domain models can be a good thing, but if we go overboard, it can
>>> become a bad thing. The question is to find the sweet spot. My gut, and
>>> often in software development guts are involved, tells me that the
>>> recognition of separate DM's is wise, but bringing that down to the level
>>> of one or a few entities (like a invoice and its rows, aka aggregate roots)
>>> makes my gut go uneasy.
>>>
>>> Basically the whole domain, inter and intra, becomes message driven. And
>>> such complete loose coupling also leads to complexer code, harder to follow
>>> business logic, and new people not easily being able to see (or trace) the
>>> big picture. Personally, that does not sit well. Like that database
>>> example; almost completely message driven software??? Hmmmmmm.
>>>
>>> Tom
>>>
>>
>>
>  
>