Here's how I currently am doing it: I use the repository pattern. I use a trait: pub trait LibraryRepository: Send + Sync + 'static { async fn create_s

Here's how I currently am doing it: I use the repository pattern. I use a trait: pub trait LibraryRepository: Send + Sync + 'static { async fn create_supplier( &self, request: supplier::CreateRequest, ) -> Result<Supplier, supplier::CreateError>; I am splitting things "vertically" (aka by feature) rather than "horizontally" (aka by layer). So "library" is a feature of my app, and "suppliers" are a concept within that feature. This call ultimately takes the information in a CreateRequest and inserts it into a database. My implementation looks something like this: impl LibraryRepository for Arc<Sqlite> { async fn create_supplier( &self, request: supplier::CreateRequest, ) -> Result<Supplier, supplier::CreateError> { let mut tx = self .pool .begin() .await .map_err(|e| anyhow!(e).context("failed to start SQLite transaction"))?; let name = request.name().clone(); let supplier = self.create_supplier(&mut tx, request).await.map_err(|e| { anyhow!(e).context(format!("failed to save supplier with name {name:?}")) })?; tx.commit() .await .map_err(|e| anyhow!(e).context("failed to commit SQLite transaction"))?; Ok(supplier) } where Sqlite is #[derive(Debug, Clone)] pub struct Sqlite { pool: sqlx::SqlitePool, } You'll notice this basically: 1. starts a transaction 2. delegates to an inherent method with the same name 3. finishes the transaction The inherent method has this signature: impl Sqlite { async fn create_supplier( self: &Arc<Self>, tx: &mut Transaction<'_, sqlx::Sqlite>, request: supplier::CreateRequest, ) -> Result<Supplier, sqlx::Error> { So, I can choose how I want to test: with a real database, or without. If I want to write a test using a real database, I can do so, by testing the inherent method and passing it a transaction my test harness has prepared. sqlx makes this really nice. If I'm testing some other function, and I want to mock the database, I create a mock implementation of LibraryService, and inject it there. Won't ever interact with the database at all. In practice, my application is 95% end-to-end tests right now because a lot of it is CRUD with little logic, but the structure means that when I've wanted to do some more fine-grained tests, it's been trivial. The tradeoff is that there's a lot of boilerplate at the moment. I'm considering trying to reduce it, but I'm okay with it right now, as it's the kind that's pretty boring: the worst thing that's happened is me copy/pasting one of these implementations of a method and forgetting to change the message in that format!. I am also not 100% sure if I like using anyhow! here, as I think I'm erasing too much of the error context. But it's working well enough for now. I got this idea from https://www.howtocodeit.com/articles/master-hexagonal-architecture-rust https://www.howtocodeit.com/articles/master-hexagonal-archit..., which I am very interested to see the final part of. (and also, I find the tone pretty annoying, but the ideas are good, and it's thorough.) I'm not 100% sure that I like every aspect of this specific implementation, but it's served me pretty well so far.