It seems to me that User should be the root aggregate in most system where an user is interacting with the system.
Would that be a fair assessment ?
Probably not. It's normal for our systems to document relationships between aggregates.
More likely candidates for the aggregate root are
- the action itself
- the instance of the process this action is participating in
- one of the domain entities modified by the action
Part of the point of aggregates is that we don't need every scrap of information in our database when making a change; we only need what we need, and therefore we only need the domain entities that manage the information that we need, and the aggregate root is going to be that domain entity we've decided to use as the entry point to communicate with the rest.
I tend to think of it in terms of locks: when we are trying to compute the effects of some new information on our domain model, we need to lock some of the existing information against concurrent change. An aggregate, in effect, is a collection of locks that we need to hold in order to make a change safely.
There's some tension: if we are missing a lock we need to hold, a concurrent data change can mess us up. If we are holding a lock we don't need, then we are blocking other changes in the system, slowing the whole thing down.
Modeling is largely about figuring out where we need locks, and understanding where we can use unlocked data instead of locked data.
In this framing, your question becomes: don't we need to lock the customer for most changes? Maybe in some domains, but as a general rule? no, we don't.
Note: since Evans first introduced the AGGREGATE pattern in his book, there's been a certain amount of debate over whether aggregates are best understood as consistency boundaries or transaction boundaries. The distinction roughly translates to "can a single transaction span multiple aggregates"?
So take care, both in your own thinking and when getting the opinions of others, to make sure that you understand which perspective is most aligned with the viewpoint.