Hi
I have a requirement to support enquries & reports for complex derived data.
I would not typically store this info but due to performance issues around deriving all of this data on the fly, I have decided to persist the data.
My initial approach was to create some event handlers for entity create/update/delete and derive the data on these events. I don't want to impact the end-user performance and thought it might be beneficial to derive this data using a background job and I still want the entity event handlers to trigger the updates,
In reviewing how the background job is used for other purposes (i.e. UserCollectedDataPrepareJob), the Background job is defined in the application service layer. However, this project is not visible (understandbly) from the Domain Service layer in which the event handlers are defined and so I am unable to enqueue the background job.
Is it advisable to create the background job in the domain layer? It seems to work OK but perhaps its not best practice? Is there another suggested approach? I don't want to cause any issues by setting the background job up in the domain layer and appreciate any guidance you can provide around my approach.
I suppose one obvious solution would be to write the events to a new table that is then polled by a background worker to process the entries but it would be nice to leverage the existing event data/worker approach.
Kind Regards Jamie
1 Answer(s)
-
1
Hi, it is fine to implement background in the domain layer.
ANZ has similar implementation like
SubscriptionExpirationCheckWorker.csnonetheless, if you are using default background job manager, you might want to consider adopting external background job manager such as HangFire, etc..., to enqueue reporting related jobs separately from the main job queue.
