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 of my app"
On Thu, Jul 23, 2015 at 2:42 PM keegan myers <keeganmyers...@gmail.com> wrote: > 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 very large number of elements in the graph. Also I'm sure components is > amazing but I try not to use any library that has fewer than a handful of > active maintainers. The prospect of one of my core dependencies in a > production app becoming outdated to the point of incompatibility is very > worrisome. > > I've also considered the fact that If I have a large number of elements > that each depend on the same thing like a database connection. I could > apply that thing to each in sequence with a monad. Basically the monad's > context would hold the database connection and then each element could be > raised into that context when it needed the connect. But, that's just my > limited Haskell knowledge coming through again. > > > On Wednesday, July 22, 2015 at 11:06:48 AM UTC-5, keegan myers wrote: >> >> 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, their invariants, and the commands each >> responds to. Predictably there are numerous operations that are similar >> between all aggregates. >> >> In my controllers I will be evaluating JSON requests and creating a list >> of commands based on those requests. I would like to dynamically dispatch >> the commands to the aggregates and let the aggregates handle them by either >> returning more commands or committing an event to the db. What is the best >> practice to dynamically send a command to an aggregate's namespace? I'm >> aware of solutions that make use of protocols and multimethods. My primary >> concern is where should I be requiring the aggregate namespaces? >> >> Is it best to do as some web frameworks do and just require everything >> (all namespaces) in some kind of application wide superset (probably using >> tools.namespace). Should I have a superset for each type of namespace (eg >> all controllers required together, all aggregates ...) or should I only >> require a namespace on an as needed basis. If so how would I achieve >> dynamic dispatch between aggregates without requiring their namespace. >> >> Sorry I'm still pretty new to Clojure. I know I can achieve this in a >> number of ways, but I'm looking for the most idiomatic approach that will >> cause the least headaches as this application grows. >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
