7 / 9 Design Principles & Philosophy

The Interface For Later

In review, a colleague asks that PostgresOrderStore be hidden behind an OrderStore interface, "so we can swap the database later".

What is on the table: no second datastore appears on the roadmap or in any RFC. The service's tests already run against a real Postgres in a container and the whole suite finishes in 8 seconds. The class has 6 public methods and every one is called. Your IDE extracts an interface from a class with one keystroke.

What is the right call?

A

Skip the interface, but add a STORE_BACKEND config value read at startup, so the eventual swap is a deploy-time flag rather than a code change.

B

Skip it. With one implementer, no planned second backend and tests that do not need a fake, the interface is an unused abstraction whose only certain effect is one more hop to read through, and the day a second store exists, extracting it is mechanical.

C

Add it. Depending on an abstraction rather than a concretion is the Dependency Inversion Principle, and DIP has no clause saying to wait until a second implementation shows up.

D

Add it, and add an InMemoryOrderStore at the same time, so the tests stop needing a container at all.