True, but the most popular method of decoupling seems to be via using an abstraction layer of some kind. At some point you need to talk to a concrete "thing".

It's also difficult to know ahead of time how much abstraction is the right amount ahead of time.

For example, you abstract disk access through an RDBMS but you might want to change DBMS so you abstract that through an ORM. But maybe you want to switch away from RDBMS altogether and go with a NoSQL solution or do everything with message queues or REST APIs? Should you abstract up another level also?

That's vertical decoupling.

Well the point of the abstraction is that you don't care about the contents, hence the term "black box abstraction".

It doesn't matter to the interface consumer what the implementation is, just that it does what the interface says it will do.

Our VFS layer has various backends which can be picked based on the client's requirements and this covers REST APIs, RDBMS and filesystems. There are various depths of stacks and abstractions hiding behind all that but to the consumer, it doesn't matter.

If it blows up anywhere in the stack, we can throw 80 levels of stack right down to the container thread if need be, but we only care about the abstraction at the point of failure.

True, if all of your classes can conform to the same interface.

When you integrate some third party black box with a different interface you're probably going to have to write at least one wrapper class.

True also. We wrap Amazon S3's client behind our VFS layer.