This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (4)
- # architecture (25)
- # babashka (23)
- # beginners (56)
- # boot (4)
- # calva (1)
- # cider (1)
- # cljs-dev (15)
- # clojure (135)
- # clojure-europe (4)
- # clojure-nl (21)
- # clojure-uk (61)
- # clojurescript (47)
- # community-development (4)
- # cryogen (11)
- # cursive (11)
- # data-science (11)
- # fulcro (25)
- # funcool (5)
- # graalvm (1)
- # graphql (4)
- # kaocha (4)
- # lambdaisland (20)
- # lumo (7)
- # meander (14)
- # off-topic (9)
- # pathom (2)
- # portkey (1)
- # re-frame (5)
- # reagent (53)
- # reitit (2)
- # ring (3)
- # shadow-cljs (32)
- # spacemacs (4)
- # sql (34)
- # testing (1)
- # tools-deps (3)
Hi, I'm trying to do an onion-y architecture with Clojure, looking for a way to use the injected repository in the domain layer. In OO you would simply pass in the repo object and then call the interface methods from the more central layer. From scattered google results it seems possible to do something similar with protocols in Clojure, but is there a best practice way of doing this, or even a wholly different pattern to use?
It's a common way to manage the subsystem dependencies and startup lifecycle in Clojure.
I saw it used in Clojure Applied as a way to set up channels for messaging between components, but don't think it touched on persistence. Thanks, I'll check it out!
Here's an example of it used to wrap the startup of database, web server, and application subsystems https://github.com/seancorfield/usermanager-example
Looking at the documentation for Component, I can see how you would use it to inject the repository connection information into the component (call it A) that uses it. But it looks to me like the examples have functions in A that rely on a specific implementation of the repository, like the following (which I'm guessing is in component A's namespace) assumes a SQL database, and even a specific schema.
What I am (maybe wrongly) looking for is a way to decouple the domain layer from the repo, so the domain layer doesn't care about how the repo is implemented, following this definition from DDD. > A Repository represents all objects of a certain type as a conceptual set (usually emulated). It acts like a collection, except with more elaborate querying capability. Objects of the appropriate type are added and removed, and the machinery behind the Repository inserts them or deletes them from the database.
(defn get-user [database username] (execute-query (:connection database) "SELECT * FROM users WHERE username = ?" username))
we use this approach for domain modelling: https://vvvvalvalval.github.io/posts/2018-07-23-datascript-as-a-lingua-franca-for-domain-modeling.html
Stuart Sierra has a talk somewhere about using abstractions over services, along with Component, which would give you what you seem to be looking for... let me see if I can find that.
https://www.infoq.com/presentations/Clojure-Large-scale-patterns-techniques/ I think this is it.
Basically you write a protocol for the service and then you can have multiple implementations, wired up via Component.
(personally I feel that is overkill because, aside from testing, I don't believe there are many situations where you really need the same API implemented over SQL and implemented over various other persistence layers -- at least, not at that sort of level)
Totally onboard with the argument that you rarely will have to radically shift implementations, and my applications are definitely not large scale. My intent is more to maintain the isolation between layers to prevent the ickiness that tends to build up if you don't, with lesser benefits being comprehensibility, testing, portability. Thanks for the articles!
If your Repository is a Component, nothing that uses the Repository needs to know how it is implemented -- the Database Component is just a dependency of the Repository so it remains internal -- and the business layer just asks the Repository for entities.
Going back to your method above:
(defn get-user [repo username] (jdbc/execute! (:datasource repo) ["select * from users where username = ?" username]))
repo-based functions need to know how to get the actual SQL stuff --
repois opaque elsewhere
(but that's really just a convention -- since Clojure doesn't have encapsulation: any code that has
repo could just pull the
:datasource out of it... but shouldn't)
(a common thing we do at work just to provide a level of indirection across components is to implement
IFn on a Component so what we'd actually do above is more like this:
(jdbc/execute! ((:database repo)) [...]) so
(:database repo) just accesses the Database Component and the extra
( ) invoke it -- via
IFn -- which in turn lifts the actual (connection pooled) datasource out of the Database Component)
That way the Repository only depends on Database and all it knows is that you invoke the Database Component to be able to use it in a SQL operation. And nothing outside of the Repository would be touching the Database at all.
I think I see. So a way to think about it is that your functions for fetching stuff from the repo in the business layer aren't totally abstracted, since you're still settling on an SQL implementation, and your business layer needs to know your database schema. But ultimately you're just tying yourself to SQL as the query language, which, you would have to write some sort of query language for the repo interface anyway. So I guess as long as your database schema is properly reflective of your domain model you're not going to confuse things too much.
You can keep them as separate as you want or need. The business layer knows about a repository against which it can a bunch of load/save/query style functions.
It is also where any translation between your business domain data structures and your persistence schema is performed.