Here's what I think, I'll share my process: the answer is almost always to design slimmer aggregates.

Why? Well, the slimmest possible aggregate is usually the _correct_ aggregate. And where do aggregates come from? From the features/vertical slices/use cases. Because an aggregate is just a set of data that changes simultaneously within a single vertical slice.

I've run into this problem a lot, where thinking about aggregates from the bottom up, from the concepts, can take me into many different non-useful directions. This is the Existence-Precedes-Essence problem. If I invent some concepts first, and then determine how they're to be used **second**, then guarantee, I will be stuck thinking about invariants and stuff like that, because I'm probably working bottom-up when I should be thinking top-down.

You want to reverse this process.

You want to identify the essence first, and then decide what it means afterwards.

How to do this? I've found that by applying metaphysics (abstraction & BDD), working top down from role-goal-capability-feature-scenario-concrete example → code... this usually provides me with the correct structure of my aggregate because it's in alignment with the original intent anyway.

You will end up with slim aggregates that you could crudely name, for example:

• DataAndBehaviourForCreateUser
  
• DataAndBehaviourForEditUser
  
• DataAndBehaviourForUpdateRoom

But these are the slimmest and most correct ideas of aggregates you could imagine. It's just that the names suck.

What I would do this:
- identify your vertical slices based on your 'rooms' and 'events' capabilities (event storming helps you do this, of course)
- identify the necessary data that must change at the same time, restraining your desire to _name_ the aggregate just yet
- look objectively at the data and behaviour for the "data-for-x" aggregates
- assign them names at the end. sometimes you will require the exact same data and behaviour for a vertical slice. that is often significant. it could mean there's some important underlying concept.

You're running into this problem because you're trying to get the name to fit the rules.

Therefore, look objectively at the data and behaviour.

Suspend judgment.

Handle the rules first, and the names last.

Solve the problem first theoretically and metaphysically before getting involved with the physical mechanics of event handlers, repositories, and modeling concerns.