✨ Outbox pattern

When processing domain events, there are two ways:

• Immediate consistency (before the SaveChangesAsync call), which is useful for cases like creating an order and its corresponding historical order where one doesn't make sense without the other. Domain events are basically part of the same transaction. We've implemented this using separate interfaces IPreDomainEvent (immediate consistency) and IPostDomainEvent (eventual consistency)
• Eventual consistency (after the SaveChangesAsync call), where domain events are basically a separate transaction. The issue we ran into with this in prod (large userbase), was that if the user closed their browser mid-request, some domain events wouldn't fire up. You solved this by queuing them up using the HTTP context while the user is still online, which is great.

That said, I wonder if you guys considered the Outbox pattern? It's kind of related to integration events, i.e. https://github.com/SSWConsulting/SSW.CleanArchitecture/issues/123, not sure what the current progress on that is

References:

• https://github.com/QuickOrBeDead/TransactionalOutboxPattern/blob/main/TransactionalOutboxPatternApp/Infrastructure/Service/EventLogService.cs
• https://github.com/QuickOrBeDead/TransactionalOutboxPattern/blob/main/TransactionalOutboxPatternApp/Infrastructure/Service/OrderService.cs#L63

It's a bit off topic, but I just wanted to say I'm really impressed by your template. You've solved the same problems we did, but in a different way. I especially like how you handled domain invariants and kinda "unified" EF Core configurations with FluentValidation. Really great job!

Start by tracing the IPreDomainEvent and IPostDomainEvent interfaces around the SaveChangesAsync flow, including how events are queued through the HTTP context. Compare that behavior with the referenced EventLogService.cs and OrderService.cs examples. The issue needs a decided scope and acceptance criteria for adding an outbox pattern before implementation can begin.