Coordinating Business Rules between Aggregates - domain-driven-design

Question

I am designing a guest check-in system for a residency hall. Residents can check-in guests, but only if these two constraints are met.
1. A resident can only have 2 guests checked-in at once
2. A guest can only be checked in with one resident
The check-in process results in a Visit.
I'm having trouble figuring out where these rules should be implemented. I started with this
var visit = resident.checkin(guest);
But that means I am modifying (or creating) three aggregates in one action:
Resident (increment # of checked in guests)
Guest (set them as checked in)
Visit = created
I don't see a concept in the domain to model as aggregate to hold these rules. Residents and guests exist outside of visits (or across other visits), so can't be wrapped in another aggregate.
I thought about a Saga, but that ends up in steps that don't make sense in the domain (like checking in the student and guest separately to see if one fails).
I could use some guidance? Is my modelling just off?

Answer 1

Creating a new aggregate B as part of existing aggregate A's transaction is usually not a problem in terms of concurrent access and consistency (since no one knows B yet). Here you have an additional invariant on the number of Visits which could be an exception to that, but it's enforced in Resident and Resident is the only entry point to creating a Visit, so everything boils down to a modification of Resident which is safe concurrency wise.
Then you have a global constraint on how many visits a guest can be in at a time. The issue has been answered multiple times on SO, but I would first of all recommend getting back to your domain experts to discuss the rule and possible variations of it, because there's a world of possibilities (eventual consistency, manual intervention, etc.) between "the constraint must be enforced and immediately consistent" and "the rule is useless".

Answer 2

In my mind the checked in state of the Resident and Guest should be viewed as a part of a 3rd AR and the incremental field in the Resident should just be incremented when a Visit is confirmed.
Approach 1:
I don't see a concept in the domain to model as aggregate to hold these rules. Residents and guests exist outside of visits (or across other visits), so can't be wrapped in another aggregate.
This does not mean that your Visit cannot hold references to the Resident and Guest.
If this 3rd aggregate is the Visit and it has states (for e.g. pending, confirmed, etc.) you can validate the state in a synchronous way and go through the states as the rule commands.
Approach 2 - Use Events for this:
There many ways to integrate events architecturally. Event Sourcing and CQRS could be a good fit here as it will change the way that you think of ARs, Entities and especially state changes.
Short CQRS definition:
Capture all changes to an application state as a sequence of events
Whatever you choose between 1 and 2 you should think of the Visit validation as a separate thing. The Resident should not validate how many guests there are at once, the Guest should not validate if 'he' is at two places at once. Those are all Business Rules related to Visits.
Some links:
I've recently answered a DDD question in a similar domain
CQRS's "official site" by Greg Young
Docs on CQRS by Greg Young
Martin Fowler's notes on Event Sourcing
When to avoid CQRS?
Tons of videos and presentations on the subject

Answer 3

Residence Hall - Aggregate Root (AR)
Guest - entity
Resident - entity
Visits - Value Object (list of Visit)
Commands for AR:
CheckInGuestCmd(guest,resident)
CheckOutGuestCmd(guest)
First command will check visits and enforce invariants than add visit
Second command will remove existing visit if it exists