Aggregate size regarding trip information

87 views
Skip to first unread message

emragins

unread,
Apr 6, 2016, 10:30:25 PM4/6/16
to DDD/CQRS
I have a trip scheduling system where a trip requires various pieces of information before it's considered complete.  Other aspects of the trip (like assigning drivers) can be added after it's initial submission.

I'm confused about aggregate size, especially if I wanted to shift towards an event sourcing pattern.  I am using CQRS with a core (wanna be?) domain model, but no event sourcing.

MANY of the pieces can be saved in pretty granular chunks.  Currently I have "Basic Info" (init's trip), "Scheduling", "Additional Info", "Budgeting", "Secondary Authorization".  These all fall under a single trip, and like I said, there will be more information added to a trip during it's lifecycle.  I opted on these "chunks" of data to make the programming model comprehensible.

So.. with a relational database, it's easy to map out fields between the code and the database to provide for granular updates.  If I want to do event sourcing, how would that work?  One Trip Id as the main entity, then all other events would reference that Id?  Or is it even possible to have these sub-components be separate aggregate roots?

More generally, how can we "keep aggregates small" but have them be the end-all-be-all at the same time?  Within the context of submission, each of these components is meaningless when removed from the larger piece.

Here's hope what I'm really asking found meaning somewhere in all these words.

Thanks in advance!

Eve Ragins

unread,
Apr 6, 2016, 11:03:14 PM4/6/16
to ddd...@googlegroups.com
Actually, I think I may have figured this out in the 30 minutes since posting despite pondering it for weeks. 

If I were to do ES with it, I should have them all reference the same "TripId" (as my root).  Where I think I was wrong before was I kept thinking in terms of "omg that's a big object..." rather than "that's a lot of little pieces from which we can build a big object in memory."

Yay or nay?


--
You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/g9uIaJuiUW4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Matt Goodwin

unread,
Apr 12, 2016, 4:02:41 AM4/12/16
to DDD/CQRS
yay
Reply all
Reply to author
Forward
0 new messages