98 karma · joined December 16, 2022
How easy one can debug such a systems easily outweighs the costs, if you have a low number of separate services.
I had huge success writing a trading system where everything went through the same `on_event(Inputs) -> Outputs` function of the core and a thin shell was translating everything to inputs and the outputs to actions. I actually had a handful of these components communicating via message passing.
This worked rather well as most of the input is async messages anyway, but building anything else this way feels very tiresome.
We just cherry-picked stuff back to release branches, if we needed a fix.
Fair deal, I'd say. Only problem is that most of the applications are from vendors, so getting problems fixed is an ordeal.
If you have a large system it makes sense to divide it into smaller independent pieces. If you have a (micro)-service architecture you have distinct services, in a monolith you might have modules.
It is a hard problem to know where exactly the boundaries between services or modules should be, in any case DDD calls the things that make sense to decouple bounded contexts.
Europe has an day-ahead auction with 1h products and continuous trading with quarter hours as the smallest product (still varying from country to country).
If you are brewing beer you have times where you have to heat it and times where it needs to sit at a given temperature. Try to optimize the process to heat during cheaper quarter hours.
Directly afterwards I got told that no one ever uses these words correctly, but the professor felt obliged to at least tell us the academic definition once.
Since this was a German lecture, some time was spent on the correct plural of schema (german: Schema). The options presented were Schema, Schemas, Schemata and everything was allowed as long as it is not Schemen (multiple shadowy figures).
Dunno why I remember this. It's the only part of the lecture I really remember.