<div>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:</div><div><br></div><div><a href="http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/">http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/</a></div><div><br></div><div>On the refactoring theme, there's also the Bowkett book, Unfuck a Monorail. Has anyone read that?</div><br><br><div class="gmail_quote"><p>On Tue, Jul 23, 2013 at 8:53 PM, Murray Steele <span dir="ltr"><<a href="mailto:murray.steele@gmail.com" target="_blank">murray.steele@gmail.com</a>></span> wrote:<br></p><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 23 July 2013 15:58, Roland Swingler <span dir="ltr"><<a href="mailto:roland.swingler@gmail.com" target="_blank">roland.swingler@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>* 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.</div>
</div></blockquote><div><br></div><div style="font-family:arial,sans-serif;font-size:13px">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.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">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?</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">[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.]</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px"><div>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.</div>
<div><br></div><div>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?</div>
<div><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">Ideally I want someone who has done both:</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">
a) starting a new app and doing it using pure OO / Hexagonal approaches</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">and</div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px">b) refactoring a standard rails monolith down into a more service-y many-apps architecture</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">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.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Anyone?</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">
Muz</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">[0]</span><span style="font-family:arial,sans-serif;font-size:13px"> </span><a href="http://devblog.songkick.com/2012/07/27/service-oriented-songkick/" target="_blank" style="font-family:arial,sans-serif;font-size:13px">http://devblog.songkick.com/2012/07/27/service-oriented-songkick/</a><span style="font-family:arial,sans-serif;font-size:13px"> - I think that's the first of 3 articles; I'm sure a Songkicker will let us know if I'm wrong ;)</span> </div>
</div></div></div></blockquote></div><br>