Domain Events with .NET - Events Dispatcher Executor

Introduction

You may remember my Domain Events with .NET post and library. I recently made some changes, and now, some more, of which I'll talk here.

I'm now introducing a new concept:

  • A dispatcher executor is a class that is responsible for calling subscribers when invoked by a dispatcher

Events Dispatcher Executor

Essentially, it's a new interface/abstraction, IEventsDispatcherExecutor. This interface - or, rather, one implementation of it - is the actual responsible for calling a subscription inside the IEventsDispatcher implementation, so all existing implementations were modified to use it.

This allows, for example, a retry strategy. I included a simple one, which can be applied by using the WithRetries extension method:

builder.Services.AddDomainEventsFromAssembly(typeof(Program).Assembly)
    .WithRetries(3, TimeSpan.FromSeconds(3));
And this is it. In the case of any exception while invoking the subscription, the executor will retry a number of times, with some delay between them, until it either gives up (max retries reached) or succeeds.
There are other possibilities, of couse, so, if you want to register your own implementation, make sure you do that before calling AddDomainEvents:
builder.Services.AddSingleton<IEventsDispatcherExecutor, MyEventsDispatcherExecutor();
builder.Services.AddDomainEvents();
Conclusion
As always, hope you find this useful, and let me know your thoughts!
Source Code: https://github.com/rjperes/DomainEvents
Nuget: https://www.nuget.org/packages/NetDomainEvents

Comments

Post a Comment

Popular posts from this blog

Domain Events with .NET

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
Read more

Domain Events with .NET - New Features

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
Read more

Named HttpClient Registrations

Introduction You're most likely familiar with HttpClient and its recommended usage , which involves calling one of the overloads of AddHttpClient . One thing that you may or may not have noticed is, even though you call the overload that takes a name for the client, it is not registered in the dependency injection (DI) container as such. So I went out to fix this! So, what we want is that any named clients can be also registered with the DI container, which will allow us to retrieve them by the service type and key: var googleClient = serviceProvider.GetRequiredKeyedService<HttpClient>("Google"); or: public IActionResult Index([FromKeyedServices("Google")] HttpClient googleClient) { ... } So, as of now, the only way to obtain the named client is by using  IHttpClientFactory 's CreateClient method: var googleClient = serviceProvider.GetRequiredService<IHttpClientFactory>().CreateClient("Google"); Which is fine, but just takes some extr
Read more