Eventual Consistency

A Domain Event is something that happened in the domain that you want other parts of the same domain to react to.

1. Decoupling the "And Also"

When a user registers, you might need to send a welcome email, create a default profile, and notify the analytics team. In a messy app, you'd put all this in the RegisterUser method. In DDD, the user entity just raises a UserRegisteredEvent. Other services 'Subscribe' to this event and handle their specific tasks independently.

2. Implementation in .NET

Use an IDomainEvent interface. Entities hold a List<IDomainEvent>. When you save the entity (e.g., in your EF Core SaveChanges override), you publish these events using **MediatR**. This ensures that the primary action and its side effects happen in a clean, decoupled way.

3. Architect Insight

Q: "Should events be synchronous or asynchronous?"

Architect Answer: "Start **Synchronous** using MediatR INotification within the same database transaction. This is easiest to debug. Only move to **Asynchronous** (via SQS/Service Bus) if the side effect is slow (like sending an email) or if you are communicating across different Bounded Contexts. This is the path from Monolith to Microservices."