Sign in to track progress and bookmarks.
A Domain Event is something that happened in the domain that you want other parts of the same domain to react to.
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.
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.
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."
Quizzes linked to this course—pass to earn certificates.
On this page
1. Decoupling the "And Also" 2. Implementation in .NET 3. Architect Insight