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 all surprised if other Clojure developers could do the same thing with less code, however whenever I try that it works for the small scale but then becomes messy in the large.
The most valuable part for me is the clean separation of my domain logic and the necessary evil of wiring up collaborators. As Michael states, Component is a trivially small library and there are a bunch of others that have sprung up. The main take-away I think from those libraries are: - separation of concerns - inversion of coupling (I am adamantly not saying ‘inversion of control’ ;-)) - flexible architecture - hexagon, n-tier etc - reloadable systems (makes development in the REPL a breeze) If you have a different approach that achieves those then sure, go for it! If it works it would be great to share that experience. ‘How do I build big systems in Clojure’ isn’t the easiest answer to reach in the beginning. For me I had to learn how _not_ to a few times first. I still have a bunch of learning to go (and hope I always will!). > On 23 Jul 2015, at 22:42, 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 > <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 > <mailto:clojure+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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.
