How to make aggregate boundaries become strongly consistent instead of eventually consistent? - domain-driven-design

Question

I have an aggregate root, Agent, in one bounded context that is devoid of authentication concerns:
Bounded context A:
interface Agent {
id: AgentId,
firstName: FirstName,
lastName: LastName,
email: Email
}
Agents are also responsible for registering new agents. That is, an Agent is also a factory for other agents.
Whenever a new Agent is registered, an event AgentRegistered is published.
Bounded context B:
Every agent needs an Account to log-in.
This bounded context B subscribes to AgentRegistered events; whenever an agent is registered, it creates an account for it (passwords are generated).
interface Account {
agentId: AgentId,
email: Email,
password: String
}
The "issue"
It is a business requirement that emails should be unique. That is:
An Agent should not be able to register new agents that have an used e-mail.
An Account should not be created if the e-mail is already being used.
It is also a business requirement that every agent should have an account.
In bounded context A, I can simply check if there are agents with the same e-mail by querying in their repository. If not, AgentRegistered event is published.
But, what happens if, somehow, there is an Account with the same e-mail? The whole process (registering the Agent and creating its account) should be invalidated.
Possible solutions?
Make the process of registering an agent and then creating an account a saga/long-running process.
A process manager would tell the Agent aggregate to register an Agent. If successful, it will tell the Account bounded context to create an account. If unsuccessful, it will rollback by telling the Agent aggregate to unregister the agent. This is ridiculously complex for something so simple.
Make Account an Entity of Agent, instead of a separate Aggregate Root.
Agent's interface would then look something like:
interface Agent {
id: AgentId,
firstName: FirstName,
lastName: LastName,
email: Email,
account: {
// wait, no need to put email here
password: String
}
}
It also makes the aforementioned business requirement that every agent must have an account more explicit.
However, it mixes concerns; Agent should not care about authentication concerns.
Is there a better solution, or am I just overcomplicating things?
Thanks

Answer 1

I am assuming there could be other personas (apart from Agents) who might be creating accounts, because of which you might end up in a situation where an email address might be present in the Accounts BC but not in Agents BC.
You can do this to check for an email address across both contexts:
You publish an AccountCreated event from Accounts BC and consume it in the Agents BC to maintain a read-only Accounts model. This model can have bare-minimum data; just the email address will suffice for this requirement. The model is read-only, so you can always wipe the data and repopulate it whenever necessary.
Now you can validate for used email addresses in both the Agents repository and the Accounts Readonly model.
Note that there will be a slight lag between account creation and populating the read-only model. So you can potentially have conflicts if two different contexts add the same email address in the same instant. But if this is a rare occurrence and you can survive the occasional blip, this is the way to go.