Interface Discovery
Which components must communicate, where the boundary of our system is, and which external dependency has to answer before the user can be told anything.
An interface exists wherever two parts must agree on something. Find them by asking, for every workflow step, who has the information and who needs it — the browser, the backend, the database, the payment provider — and you have the interfaces before any of them has a shape.
The boundary of the system is the line between what you can change and what you can only call. Finding it — payment provider, email, image storage, the customer's browser — tells you which interfaces are contracts with a stranger and which are conversations with yourself.
Once the boundary is drawn, each edge crossing it is a contract to write — in your terms, not the stranger's. The interface says what your system needs from the other side and what it promises back; the provider's SDK is an implementation of that, not a definition of it.
Checkout depends on cart, inventory, payment and orders. Not all of them must answer before the customer sees a result; asking which ones must — and what you would tell the customer if the others are still working — is the decision that separates a synchronous call from an asynchronous one.
An external system can fail, be slow, change, rate-limit you, and repeat itself. None of those is a bug in it; they are properties of being outside. The interface you design around it either accounts for all five or discovers them one incident at a time.