For instance, to create a "User" we need the PutItem API from DynamoDB [1]. Similarly, to retrieve a "User", there's the GetItem API [2].

Instead of making references to these APIs all over our codebase, we have a single `db-interface` module, which implements `get_user` and `create_user` functions. Each of these functions has an interface: they expect specific arguments with corresponding types. This interface is modeled against our data domain, not DynamoDB data domain quirks.

Inside the `db-interface` module, we implement the conversion from our data domain to Dynamo's. We also have general-purpose functions, like `create_item` and `get_item`, so that `get_user` and `create_user` are pretty much wrappers and only serve the purpose of defining the interface for interacting with the "User" data object.

The rest of our code only interacts with our internal interface, never with DynamoDB APIs directly.

If we were to switch database, we only need to re-implement the general-purpose functions (e.g. `create_item`, `get_item`).

May sound like a lot of work, but it took only a handful of days to implement the entire interface mapping everything we needed from DynamoDB.

Hope this helps clarifying a bit the application of this concept (develop for an interface, not an implementation) in the context of interacting with databases.

[1] https://docs.aws.amazon.com/amazondynamodb/latest/APIReferen...

[2] https://docs.aws.amazon.com/amazondynamodb/latest/APIReferen...