Comment by benjaminwootton
5 years ago
This pattern in large part came from SecDB at Goldman, and then a few people who moved to moved to JPMC and BAML.
Dependency graphs are an elegant solution to risk management and pricing etc. There’s a reason this approach works in IBanks.
Check out Beacon.io which is the a SaaS implementation from the same team.
> Dependency graphs are an elegant solution to risk management and pricing etc.
Dependency graphs are not a solution to risk and pricing. They are, in certain circumstances, a very useful tool. That's all. They also scale notoriously painfully.
Putting a dependency graph as a mandatory component in your risk system was one of the worst technical decisions I've come across (and I've been doing this lark a long time).
Wouldn't an observer pattern work better? The graph itself could even be used to instantiate subscriptions in a pub/sub system where changes in underlying pricing could be dealt with via an event queue. Compaction and debouncing could be applied on top of the queue to avoid lots and lots of redundant execution.
> Wouldn't an observer pattern work better?
Better as a solution to what problem? In some cases a dependency graph is an excellent solution. In some cases it's not. In some cases it's fine for small graphs but scales poorly as it can be very hard to reason about (as attested by pretty much anyone who's supported a really big spreadsheet).
But that's the point; it's a really useful tool. Sometimes.