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.
I think I read here on hackernews that the Mona Lisa doesn't look at all like it did when it was freshly made. If I look at the restored copy https://en.wikipedia.org/wiki/Mona_Lisa_(Prado)#, I at least find the silk very nice.
I am on-call for a week every ~8 weeks. I get 500 € and two additional days of vacation for it. If I do get a call, the additional hours go to my time account.
Fair deal, I'd say. Only problem is that most of the applications are from vendors, so getting problems fixed is an ordeal.
> DDD is against the idea of having a single unified model; instead it divides a large system into bounded contexts, each of which have their own model.
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.
Define that function directly in the place where it is used (e.g. as a lambda, if nesting of function definitions is not allowed). Keeps the locality and makes it obvious that you could just have put a comment instead.