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

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