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!