[LRUG] Objects and on Hexagonal Rails

[Murray Steele]

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 ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20130723/220a6bad/attachment.html>