When we set out to implement a user story, we shouldn’t tackle it as a series of steps we must perform in order, without any help from others. Rather, we should act like a contractor charged with employing professionals from different fields to achieve the goal collaboratively. These professionals would be sought after even if this user story never existed.

This framework applies directly to the Dependency Inversion Principle. We should aim to discover stable abstractions that are meaningful on their own.

A script at the far end of the spectrum acts as if a single worker is doing all the heavy lifting without collaboration. To modularize a script, we need to step back and identify the stable abstractions that come together to do the job. If you don’t step back, and instead simply split the script into smaller steps, you provide no value. These steps do not embody stable abstractions.

A simple litmus test to determine if an abstraction is relevant is to ask: Would this abstraction make sense if its consumer never existed? If you deleted the script, would you also delete these so-called “modules” you separated from it? If so, they were merely steps, not true modules.

Throughout this article, we have emphasized abstractions that are meaningful on their own. To this end, when applying dependency inversion, we should strive to avoid interfaces molded by the whims of the higher level of abstraction.