Address Domain Event Publishing Limitation

[JustinianErdmier]

Currently, if the user configured the DbContext to use the library's built-in interceptor, they are forced into three major constraints:

1. ALL domain events captured by entities tracked by the DbContext will have their domain events cleared and published when a call to SaveChanges() or SaveChangesAsync() is made.
2. If using the built-in interceptor, users are not given the option to trigger event publishing by other context actions.
3. No ability to say which domain events should be triggered by the save changes action or by other triggers.

As a user, I should be able to configure and/or capture my domain events in such a way that I have full control over when and how they are triggered to be published. Additionally, I should not be limited to only triggering publishing from save changes.

• Add additional interceptors to cover EF Core's other DbContext actions.
• Add more detailed interface markers for domain events that will determine who/how they are triggered. (i.e., instead of a single IDomainEvent, there could be ISaveChangesDomainEvent and IRuestFailedDomainEvent, etc.).
• In addition to/as opposed to more detailed domain event interface markers, the IHasDomainEvents interface could also define additional collections for events designed for other triggers.
  • I do see a major downside with this option. The designated purpose for each collection is essentially hardcoded. Adding additional options would require manually adding them and updating the library. By providing a base interface and then more specific interfaces on top of it, not only does this allow me to provide common desired triggers out-of-the-box, but also allows the end-user to build on top of it.
• Seeing as to how this would be a breaking change, this would be a good opportunity to rename PublishDomainEventsInterceptor to be more accurate (e.g., PublishDomainEventsOnSaveChangesInterceptor).
• Additionally, the IHasDomainEvents interface should be renamed to IHaveDomainEvents.

[JustinianErdmier]

Issue #52 has brought to my attention that MediatorCore currently forces consumers to have a dependency on EF Core even if they are not using it. Base publication triggers should reside in MediatorCore, but then triggers with dependencies should go into their own respective child libraries (e.g., MediatorCore.EfCore, MediatorCore.DynamoDb, etc.).