Let’s say I have a dotnet project that is structured like the following
This is loosely assembles what @alexey.zimarev describes in his book and ESDB webcasts. It builds the context for my customer domain.
So far so good. Now I have the “requirement” that every finalized customer registration needs to be exported to legacy systems. These legacy systems should not be changed for now, and rely on a file based export.
As this is kind of a temporary requirement my idea is to put this export related functionality in a separate process/service. Separate it because if not needed anymore, just kill the process/service and call it a day.
But this leads me to the following questions
If this export process is externalized, and I still want to store the fact/event that the user entity export was done, I will ultimately end up with a 2 phase commit, as I have to store the event and create the export file. Nevertheless I would have the same issue no matter in what process the file export is created I guess. So how to make the file creation and storing the fact atomic?
The 2nd question is directly related to the idea of separating the export. If I want to export the user I can either
- listen to all events related and build my export view on the fly
- or just act on the final exportable status and build the export view on demand.
Basically then go to ESDB and assemble the exportable “view”. As no too many events will be involved until this final status is reached it seems feasible.
No matter how I build the export, i will need my code shared across to the other implementation/service.
Is this something you should avoid in general? If not it ads complexity on its own. Nuget package? or git submodule and so on?
It seems a lot easier to just keep this inside the same project. As it belongs to the domain in general it might be the correct fit. But then the temporary nature triggers a “move it out” reflex inside me.
Anny input appreciated. At lot to learn for me.