[LRUG] Evaluating Hexagonal/SOLID Principles in Rails
Matthew Willson
matthew at playlouder.com
Wed Jun 20 07:17:13 PDT 2012
Hey all
Finding this debate quite interesting. My slides from a Barcamp a while back, although a bit old might be of interest to some:
http://www.slideshare.net/andreajezovit/scaling-up-ruby-codebases
This was based (with hindsight, as always!) on experiences building up a large-ish configurable web services platform in ruby, and while not directly about Rails, could be relevant in places. Essentially the debate around, as a ruby codebase grows, how do you know when to start making more 'enterprisey' architectural decisions, and when can you get away without them. (Feel free to ignore the scala stuff, some of which I'd probably be a bit more reserved about advocating now.)
One difference in philosophy I've noticed is with DSLs. Less mature libraries seem to let a cute DSL syntax drive their implementation, resort to whatever metaprogramming hacks are necessary to make things work under the hood, and tend to use global/singleton state (e.g. class- or module-level variables) for most of their configuration.
More mature extensible libraries treat the objects, responsibilities, interfaces and interactions more as the core drivers of the design, with the cute DSL more as a wrapper sitting on top, which helps you wire up those objects concisely. Configuration is done on instances rather than having to be done globally or at class-level. This is really the best of both worlds to me (clean extensible, configurable design AND concise ruby-ish DSL) but could be overkill depending on the kinds of projects the library's intended to be used in.
Probably my main lesson would be: YAGNI and all that, and don't blindly throw enterprise patterns at things without a real sense for the pain points they're addressing. BUT if you see yourself growing into more of a platform than a one-off app -- monitor things closely, know the pros and cons, and at a minimum try to avoid opinionated decisions, frameworks and libraries which will actively *get in the way* of a truly modular OO design further down the road. (This isn't necessarily a diss against Rails, which I've honestly not used much recently, but probably somewhat contrary to the DHH philosophy.)
Anyone interested in this sort of slightly enterprisey but hopefully still fun and Ruby-ish platform development might be interested to talk MSP about it (some of whom I know are lurking :-)
Cheers
-Matt
More information about the Chat
mailing list