Hi Keegan.
I’m not sure I would call them abstractions (as they are pretty opaque), I
would say they are more about one-thing-to-do-one-thing :-). I do agree that
the level of boilerplate code (which I think is actually what you are referring
to) has echoes of Enterprise Java. I wouldn’t be at
This is component, all of it:
https://github.com/stuartsierra/component/blob/master/src/com/stuartsierra/component.clj
-- that's well below the size threshold where I'm comfortable saying "if
someone else is maintaining it, that's one less thing for me to do; if they
ever stop, this'll become part
It's an interesting approach, the extra layers of abstraction feel
reminiscent of my days with enterprise java. As far as components go I
think I might be able to achieve a similar effect using prismatic/plumbing
graphs. The lazy compile option for graphs may be beneficial when there are
a ver
Ah, one of the eternal questions, so there isn’t really a ‘do this’ answer. My
experience:
[multi-methods/protocols]
You need to include the namespace they are compiled in for those methods to
take effect and because they are defn’d at the root you cannot provide
collaborators easily. You cann
I've begun building a rather complex web application in
Clojure/ClojureScript. After some evaluation I decided that CQRS + event
sourcing would fit the requirements well. As such I have a bunch of
aggregates (models) each in their own namespace that contain all the
applicable record definitions
