Development with a Dot

Introduction You may remember my post on the Domain Events framework I created, a few days ago. Well, I've been working on it, cleaning things a bit, correcting a few bugs, and I introduced two new features/concept:  Event interceptors can now return a boolean from the BeforePublish event in order to cancel the publication of the event Event transformers Changes to Event Interceptors The changes to the IDomainEventInterceptor / IDomainEventInterceptor<TEvent> interface look like this: public interface IDomainEventInterceptor { ValueTask<bool> BeforePublish(IDomainEvent @event, CancellationToken cancellationToken = default); Task AfterPublish(IDomainEvent @event, CancellationToken cancellationToken = default); } public interface IDomainEventInterceptor<TEvent> where TEvent : IDomainEvent { ValueTask<bool> BeforePublish(TEvent @event, CancellationToken cancellationToken = default); Task AfterPublish(TEvent @event, CancellationToken cancellat

Introduction Domain Events  is a pattern and concept made popular by Domain Driven Design . A Domain Event is something that happened on your system and you want interested-parties to know about. It is a way to publish information in a decoupled, usually asynchronous, way. A publisher publishes (raises) an event, and interested subscribers receive a notification and act accordingly. A subscriber can also be a publisher, of course. In this post I'm going to present a Domain Events library for .NET. It's not the first time that I write about decoupling messages and subscribers in an application, I implemented a few years ago the Postal.NET library which does something similar. Mind you, there are many implementations out there, MediatR coming first to my mind, but this is mine. I obviously got some ideas from other implementations, but mine is substantially different from all the others. Concepts First, a few concepts: An event is just some class that implements IDomainEvent A