Services, Models, Repositories, Tables
Regarding the repository pattern and where we fit architecturally:
Right now Prisma Client is essentially part of the "data tier" (e.g. the Buyer table in this graphic). These tables map directly to what the database offers.
The domain model layer is higher-level and describes the nouns and verbs of your business. These verbs may interact with multiple tables and other services like queues and mailers.
Normally the domain model layer is built on top of the database client. In our case because our database client is so feature-rich, it may make sense to "mixin" or extend the database client with our domain model. One important thing to keep in mind is that there are use cases for one model to depend on multiple underlying tables.
The repository pattern is an additional abstraction for combining domain models into higher-level services. You reach for this pattern when you find yourself repeating the same model actions in many different controllers/resolvers. It's overkill for small applications.
For us, I think it makes sense to focus on enabling computed fields, validation, permissions, etc. in the model layer. Once we have that foundation we can start talking about grouping models into repositories.