Anyone who works on a mature software system knows the problem: for a seemingly small change, we suddenly need to know a surprising amount about other methods, classes, modules, services, or even external systems. The more internal details, implicit assumptions, and special cases we have to keep in mind, the more time changes take, the higher the risk of mistakes, and the more expensive maintenance becomes.

But what changes if we consistently treat each of these relationships as an API, from systems and services through modules and classes down to a single method call? The same core questions then apply at every level: What does the API need to express so that the interaction works correctly? What do both sides need to know about each other? And who should be responsible for what?

This talk shows how the API perspective helps us recognize such interfaces at every level and improve them step by step whenever we change existing code. This way, we need to keep fewer details about other parts of the system in mind and can focus more on the domain itself.