I interpret Kartik’s point as stating that it’s counterproductive to split naturally integrated domains (terrain) for the convenience of map making.
But when you start to deal with performance problems, a high level view of the internals can be invaluable for finding the problem.
Something like a CRC diagram is invaluable
http://www.agilemodeling.com/artifacts/crcModel.htm
To clarify, this then allows you to look inside of the API (to bunch of things talking over more APIs, yay microservices). Then you can see which bit might be causing the issue with the bit of the larger black box you are talking to
Nope. To clarify: https://news.ycombinator.com/item?id=30019146#30038853
People also often define “leaky” as “can break”, which is kind of unreasonable. The notion of a data stream across a network is an abstraction over many layers of complexity. People often say it’s leaky because of packet loss and failed connections, but that’s not a leaky abstraction unless you define the abstraction to not include a failure mode.
- Kartik argues for better mutual understanding and additional communication
- Team Topologies states you should match system boundaries to team boundaries, specifically when cognitive and/or communications load have grown unmanageable due to team size and/or software complexity
On the surface, Kartik is arguing against abstractions and Team Topologies is arguing for abstractions, but both stances feel valid to me. It feels like there's a spectrum of tradeoffs here. Is this essentially an analogue to the tradeoffs of monolith vs services?
- For small teams, by all means keep abstractions low and communication high--monolithic systems and less division of labor is ideal and your team will gel better for it. Your team is probably not large enough to warrant either services or division of labor, so stick with the monolith.
- As an organization scales, you end up with an n^2 communication edges problem, and at this point division of labor is necessary to limit the cognitive and communications loads.