5 ms·
I think what we're seeing here is Conway's law in action. Most places I've worked don't define their bounded contexts based on separation of concerns, but rathe
by etripe 6y ago
I think what we're seeing here is Conway's law in action. Most places I've worked don't define their bounded contexts based on separation of concerns, but rather on separation of reporting.
That is: team A has been given arbitrary stewardship of generic app functions T, U, V based on management purview. Team B has been given stewardship of generic functions W, X, Y, Z. So the bounded context is along those lines. But wait, both V and W are related to billing, you say? No matter!
Since the cliché is you can't solve people problems with technology, the same applies to micro-services: it's much harder to convince managers to shift accountability than it is to move the code from one micro-service to another. Even if you do move the code, you get to have your shit and eat it, too.
- rualca 6y ago> I think what we're seeing here is Conway's law in action. Most places I've worked don't define their bounded contexts based on separation of concerns, but rather on separation of reporting. You're not wrong. I mean, one of the goals of microservices is to peel off responsibilities to a service that can be owned and managed by a small team. However, what I've been seeing in these anti-microservices rant is developers struggling to acknowledge the need to reason with loosely coupled interfaces, reason about partial system failure modes that were always there in monoliths but we're either ignored or turned into critical system failures, and the microservices tax.
- Glyptodon 6y agoI think some of the problems I've encountered are related to teams trying to do microservices before each service can actually have a small team.
- Glyptodon 6y agoThat pretty much sounds like my workplace in action.