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

Jorge,

If the World really needs anything more than just a number of countries per
continent (if at all, wouldn't that information be better contained in each
continent? A world might be interested in the total sum) to be able to
enforce its own constraints, invariants, business rules and transactional
consistency you could very well introduce a dumbed down type that contains
the necessary information.

Best

Dennis
On Aug 29, 2013 10:06 AM, "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
>>>
>>
>>
>  
>