I have a question about web-hooks and how they map to domain driven events.

I am modelling a system using domain-driven design. Without going into the details, there is a domain service (a machine-learning prediction) which takes some time to run. The user would like therefore to send "batches" in an asynchronous manner. At a high level, I have a REST API (a controller), which sends commands to my application (use cases), which manipulates my domain model.

On the modelling side, I think of the completion of a prediction and of a batch as domain events. On the API side, I am considering a "subscriber" pattern, where the API user could register an endpoint and choose which events she would like to receive. For example, she could subscribe only to the "Batch Done" event, or to both "prediction done" and "batch done".

My question is whether the concept of subscription/subscriber should be part of my domain model. In other words, where should I store the "endpoint" associated with a subscriber? In the domain model or in API-level storage?

On the one hand, I feel it does not belong to my domain, because it is a technical concern that only relates to my REST/HTTP API. A different API (say a synchronous gRPC for example) would not have that info. Does it make sense to store it into a "api-level" storage? On the other hand, the same argument applies for a user email, which I could see as a email-protocol identifier (still I directly put it into my domain model).

Am I splitting hairs here? Is there a "common" way to do that?

Many thanks in advance :-)

Franck

CodePudding user response：

No I would keep this very much seperate - webhook to me is a presentation/hosting concern.

Be it event bus, or proxy thereof via a webhook or gRPC sending a stream of events, it is ultimately the same async flow just presented/implemented in a different way.

Events such as PredictionCompleted make sense, and allow your API to be modelled in an async fashion which you seem to be very much on the right path.

Then event handlers can pick this event up and dispatch over the various notification methods, you can have one for each... Email, gRPC, eventbus, discord etc. Each of those handlers would need some form of mapping locally within that presentation layer so subscribers can be notified.

I would use a mediator pattern (mediatr in .net) and then have handlers for each, if in same process. If you are scaling this out to multiple processes then makes sense to have all these event handlers hanging off an event bus, which then fire off their individual converters (i.e. post to discord) on receipt of the event from the bus, or even post to another external subscription message bus.