Decoupling
Reducing how much one part of a system needs to know about another, so each can change without dragging the other along with it.
Two pieces of code are coupled when a change to one is likely to force a change to the other. Decoupling is the act of reducing that dependency, not eliminating contact between them, just narrowing what each one is allowed to know about the other.
A business rule that calls db.prepare(...) directly is coupled to SQL: change the database, and the rule changes with it. Put an interface between them, findConflict, save, and the rule now depends on a contract instead of an implementation. The database can change behind that interface and the rule never notices. The same shift is easier to see than to hold in your head from prose alone: on the left, the rule reaches straight into SQLite; on the right, both sides point at the same interface instead of at each other.
That's the whole trick. Decoupling isn't about having fewer connections in a system, most parts of a real system still need to talk to each other. It's about which side of the connection is allowed to define the terms. The reusable, stable part should define the interface; the specific, swappable part should depend on it, not the other way around.
The test for whether something is actually decoupled: can you replace one side without touching the other? If swapping SQLite for Postgres means rewriting the business rule too, they were never decoupled, just spread across two files.