Hmm… I think that @factoryd is on to something here perhaps. Greg Young warns on a few occasions “please dont tell me that you’ve built an event sourced system”, meaning that it only makes sense applying the pattern to a small part of your system where it’s actually really needed, not least because ES comes with a ton of overhead. There are actually quite a few wartime stories about botched ES attempts, and a common theme is attempting to force ES everywhere.

The reason I’m saying this is that it looks like you should perhaps think about separating your app into 2 parts: the first should only concern itself with the polling aspect (configuration screens, external apis etc.) that will produce commands that will then be pushed on to the second part of your system which should only be concerned with accounting (your core business, which may actually benefit from ES), that will simply consume the commands from the first part, convert those into events, apply them and finally publish them for the rest of the system to act upon (you know, the canonical ES flow).

Again, that would be my advice: do not mix a ton of different concerns in an “event sourced application” because this pattern tends to multiply the effects of bad system design decisions

OK, I see. Perhaps it’s worth a shot then as a learning experience! But if this solo/personal/internal project ends up being used everywhere (as infrastructure projects are sometimes wont to be) you should make sure that you will be given the required time (by your manager for example) to revisit your designs in case they end up not fitting the problem