I was doing some app, and there, if one model was updated it had some pretty much domino update effect on many other models.
Firstly I’ve just called the needed classes right in needed method. But that was ugly, and I’ve tried to decouple them with pub/sub.
But actually that doesn’t solve the problem much either, you anyway have to subscribe needed objects and broadcast from method so it’s a bit better but it’s not far from first approach. Rails callbacks are pretty good for that task, but it’s suitable not for all cases and not explicit on what happens.
So I’ve just made services whose sole responsibility was managing classes on events, and in models 've just added bunch of methods like on_some_event. So I’m just calling that managing class, and it does it’s job, like:
class Contract def approve(by_user) run_approval_procedures(by_user) MysteriousManaginService.on_contract_approval(self)
and than in that class im just calling needed models and etc like
class MysteriousManaginService class << self def on_contract_approval(contract) UserNotification.on_contract_approval(contract.id) contract.executor.on_contract_approval(contract.approvers) #other things that need to be done
yeah that class knows too many things itself, but it is it’s responsibility to do so, and at least you easilly controll the flow and main players are not knowing each other directly. And in case something is changing, you just open that class and know what and where to change things.
So is it architectually wrong approach? What do you do for decoupling in that cases?