there will be always at least a couple schools of thought among clojurists when it comes to abstraction. I've participated in multiple teams where protocols were chosen and they did exactly what we foresaw - testable, explicit code. Do they resemble of Java codebases? I guess so, but one would only fool himself to think that 100.00% of OOP/java practices are bad. As far as tooling is concerned, I think clojure-lsp added protocol support recently (if it wasn't there already). It's not out of the question for CIDER either.

One article good that describes the problem and one solution tradeoffs is https://www.jamesshore.com/v2/blog/2018/testing-without-mocks the author has a video serie in which he live codes that solution. He uses oo but it also works using a more functional style.

Have a look also at this talk about the hexagonal architecture https://youtu.be/0EX3UIl-Sd8

> Using protocols to specify interfaces in a Repository pattern seems rather Java-ish and not like idiomatic clojure Protocols are fundamental in Clojure, and are fully idiomatic. They provide several advantages over Java interfaces and are a fine mechanism for introducing abstractions to Clojure code. I maintain a large codebase where we use the Repository pattern with protocols more or less like in the Juxt article. I highly recommend trying this route for cleaning up your code. > Simply speaking, routes get an integrant system map and this is plumbed all the way to the bottom, with different levels peeling the IO bit they need out of the system map. Try making a repository protocol with some related DB functions (for example) and add this (or rather, an implementation of this protocol) to the Integrant system. Then refactor the domain code to use this abstractions instead of the concrete bits.

@U06BEJGKD Assuming you use SQL, are your transactions inside the Repository boundary?

No, I have a with-transactionfunction (and an accompanying macro for sugar) that wraps code that should happen in a transaction. Multiple Repository functions may be called inside the transaction, even from different Repositories (in violation of DDD orthodoxy, no doubt, but useful when there is low write contention).