GoRuCo 2012 Hexagonal Rails by Matt Wynne
Confreaks1 HN recommender · recommended in 1 month, 2012–2014
talk · intermediate · 2012–2014 on HN
Matt Wynne's GoRuCo 2012 talk on why Rails apps get hard to change as they grow, and how a ports-and-adapters hexagonal architecture separates application logic from the framework.
HN cites it as a resource for decoupling Rails code and for faster tests.
Up next
15 mo on HNRailsConf 2014 - All the Little Things by Sandi Metz
Confreaks
15 HN recommender · 2015–2025
14 mo on HN"Simple Made Easy" - Rich Hickey (2011)
Strange Loop Conference
14 HN recommender · 2022–2026
13 mo on HN"Making Impossible States Impossible" by Richard Feldman
elm-conf
9 HN recommender · 2017–2026
12 mo on HNHow To Design A Good API and Why it Matters
Google TechTalks
12 HN recommender · 2011–2025
11 mo on HNThe Value of Values with Rich Hickey
InfoQ
10 HN recommender · 2014–2023
10 mo on HNOverwatch Gameplay Architecture and Netcode
GDC Festival of Gaming
16 HN recommender · 2019–2025
11 mo on HNSolving Problems the Clojure Way - Rafal Dittwald
Clojure/north
10 HN recommender · 2019–2025
10 mo on HNLecture 1A: Overview and Introduction to Lisp
MIT OpenCourseWare
10 HN recommender · 2019–2026
11 mo on HNAlan Kay - Normal Considered Harmful
powerfuloutlet
10 HN recommender · 2012–2026
10 mo on HNA Philosophy of Software Design | John Ousterhout | Talks at Google
Talks at Google
11 HN recommender · 2018–2026
10 mo on HN"Uncle" Bob Martin - "The Future of Programming"
Paul Stringer's Mobile Tech
10 HN recommender · 2016–2022
10 mo on HNEffective Programs - 10 Years of Clojure - Rich Hickey
ClojureTV
10 HN recommender · 2017–2026
3 comments from Hacker News
Was going to say the same thing. Models should not know or care about background queues or mailings, and callback use has always caused problems for me later on. Nothing against the OP, it does explain a common edge case that many people will run into and for that it's a good article, but I wish more people would see the violations of SRP going on here and try to lead people away from this trap. I'd recommend watching ▶ this video (Hexagonal Rails GoRuCo talk) for one way to re-architect to get away from these inter dependencies.
Rails used as intended can be a real pain to upgrade, I agree. Recently I have been developing applications in the "thin-model, thin-controller, with a service layer and external API wrappers" style, as espoused by Gary Bernhardt [1] and others [2] [3] [4] [5]. I upgraded to the latest Rails this morning on one app, and apart from swapping the Money gem to use the git repository, until they have a new version out with compatible dependency, it went smoothly. All the specs and acceptance tests passing with no alteration required. [1] link [2] link [3] link [4] link [5] ▶ this video
Am I only the only one that doesn't find 'All tests in 4 minutes, all model tests in 80 seconds' very impressive? It sounds like a really long time to me. You know what could increase the speed dramatically.... decoupling. I also think decoupling phrased in the context of the Rails 2 to Rails 3 upgrade, where pretty much everything changed, makes perfect sense. Imagine just having a few wrapper classes that spoke to Rails and only having to adapt them. Sounds good to me! Bernhardt: Boundaries link Weirich: Decoupling from Rails link Wynne: Hexagonal Rails ▶ this video