In the other topic I mentioned the repository - it’s essentially a Façade which wraps your persistent storage access technology - whether it’s something as low-level as ODBC or high level as a relational mapper like Ecto. The only thing the context contributes is the boundary for the functionality of that (context’s) repository (which is necessary to support the capabilities of the context).
The more significant issue in terms of coupling are the data types (shape of data; structs) which are used to interface with the repository - for example if the repository returns and accepts types that are generated with the assistance of Ecto.Schema for use with Ecto.ChangeSet then the repository has failed to decouple the application from Ecto. On the flip-side a lot of the value that Ecto can provide is lost if the application is successfully decoupled - you’d essentially have to implement your own Unit of Work.
Another perspective is to simply, deliberately accept the coupling between, for example, Ecto and the rest of the context’s capabilities - provided that the context is small enough to be easily replaced in it’s entirety when the persistent storage technology changes sometime in the future.
