[LRUG] Objects and on Hexagonal Rails

[Stephen Best]

I've been working on a green field SOA project with the team at Cambridge
Healthcare recently and we've very much embraced the whole 'Hexagonal
Architecture' paradigm, following the EBI / EBC (entity, boundary,
interactor / controller) pattern mentioned by Uncle Bob is his
"Architecture the Lost Years" talk.

http://www.youtube.com/watch?v=WpkDN78P884

We started off with a hexagonal-ish Rails app, used devise and the service
layer pattern and soon moved away from Rails and ported our app to Grape.
The porting process was not a big problem.

The awesome stuff is:

* Adding / changing features is very easy.
* All our objects are very simple.
* Tests are lightening fast. Unit test run measured in ms. Full integration
suite run through Faraday / Rack test takes <5s, including startup times.

The caveats are:

* It takes a little longer to get going.
* Those tough decisions about how to do things are frequent at the start,
make sure have at least two experienced/obsessed engineers to pair on /
argue about them.

Gerhard Lazu and myself are planning to present some of our ideas and code
samples as soon as our apps have proven themselves in production.

Stephen Best
Ruby / Javascript developer, Ember.js evangelist.

+44 7745 790523
linkd.in/stephenbest
github.com/bestie
@thebestie


On 23 July 2013 21:25, Aanand Prasad <aanand.prasad at gmail.com> wrote:

> This comes to mind as a practical application of some of the techniques we
> usually discuss at a higher level, though perhaps it's not all that radical:
>
>
> http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/
>
> On the refactoring theme, there's also the Bowkett book, Unfuck a
> Monorail. Has anyone read that?
>
>
> On Tue, Jul 23, 2013 at 8:53 PM, Murray Steele <murray.steele at gmail.com>wrote:
>
>>
>> On 23 July 2013 15:58, Roland Swingler <roland.swingler at gmail.com> wrote:
>>
>>> * What sort of developers will you be hiring? Junior & mid-level
>>> developers have a lot of resources in terms of books, community, other code
>>> examples, etc. to learn how to follow rails conventions really well. Going
>>> for the Objects on rails approach forces you into making many more, harder,
>>> decisions - what is the scope for these decisions to be made poorly?
>>> Appealing to authority, I seem to remember in the Domain Driven Design
>>> book, Eric Evans advising that you shouldn't try and apply DDD if the
>>> modelling skill in your team isn't high.
>>>
>>
>> I think this is key.  If you build a standard rails app you are in very
>> real terms "on rails"; there's a single approach you can take to build the
>> app and you don't really have to think much as there's so much What Has
>> Gone Before wisdom out there.  If you take the OO / Hexagonal approach
>> pretty much everything you do is going to require A Decision About
>> Something New.  Like Roland, I don't think that's a bad thing, but I do
>> worry that it means it's easier to make poor decisions.
>>
>> There's lots of people saying "Hey, you should totes do stuff this new
>> way. Maintainability FTW!" but not a lot of "and here is how. WOO!".  Maybe
>> someone can prove me wrong though; do you know of any good, real-world,
>> examples to look at?
>>
>> [aside: Objects on rails is good but, as someone already said, it
>> describes a toy app and it's hard to extrapolate upwards to the complexity
>> we'd really face.  The songkick tech blog series[0] about their approach to
>> splitting an app into services is also good.  I want more.]
>>
>> It occurs to me that I have a bunch of tools to hand for refactoring
>> single objects (extract method, identify and extract collaborators, etc).
>>  Handily these tools can be applied to the problem in my brain before I
>> even start writing the code, so I can knock up something reasonable at
>> first pass without the refactoring step.
>>
>> What I don't really feel like I have a similar set of tools for doing
>> this across a whole app.  Unless, maybe I do?  Is it just the same thing,
>> applied macroscopically?  Does it even make sense to think in terms of
>> red-green-refactor across a whole app architecture?
>>
>> Ideally I want someone who has done both:
>>
>> a) starting a new app and doing it using pure OO / Hexagonal approaches
>>
>> and
>>
>> b) refactoring a standard rails monolith down into a more service-y
>> many-apps architecture
>>
>> to come an tell me (us) what it's like and which is easier.  Also explain
>> what pitfalls there are (for example I imagine one obvious one is chopping
>> it into the wrong services too early), and what patterns there are for
>> spotting obvious things.
>>
>> Anyone?
>>
>> Muz
>>
>> [0] http://devblog.songkick.com/2012/07/27/service-oriented-songkick/ -
>> I think that's the first of 3 articles; I'm sure a Songkicker will let us
>> know if I'm wrong ;)
>>
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20130723/8e787987/attachment-0003.html>