[LRUG] Objects and on Hexagonal Rails

[Aanand Prasad]

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