Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Hexagonal Rails

Hexagonal Rails

In the early days of a project, Rails absolutely dazzles.

Tragically, the very same forces that make it so easy to add new features to a brand new Rails application are the ones that start to hold you back as the number of features grows.

Your test suite gets slower and slower, and refactoring becomes more and more of a chore. Everything seems coupled together, and it's hard to see much of a structure other than the MVC triad.

In this talk, Matt explains why this happens, and shows you a way out, using a ports-and-adapters or hexagonal architecture to introduce a separation between your application's domain logic, and the Rails framework.

This talk is suitable for advanced Rubyists who want to enjoy the benefits of Ruby's great Object-Oriented and functional programming features in their Rails applications.



June 23, 2012

More Decks by mattwynne

Other Decks in Programming


  1. @mattwynne GoRuCo, 23rd June 2012 Hexagonal Rails

  2. None
  3. None
  4. None
  5. None
  6. Caveat

  7. None
  8. None
  9. and then...

  10. None
  11. Why?

  12. None
  13. Connected

  14. Modular

  15. None
  16. None
  17. Modular, in the large

  18. None
  19. What does it do?

  20. Web UI API Project Topic Publisher User Membership

  21. No, What does it do?

  22. Metaphor

  23. Librarian Bouncer Web UI Controllers API Project Topic Publisher User

  24. Librarian Bouncer Web UI Controllers API Project Topic Publisher User

  25. Modular, in the small

  26. Protocols

  27. None
  28. Your domain model is not in your classes, it's in

    the communication patterns between the objects at runtime. — Steve Freeman & Nat Price
  29. Your domain model is not where you think it is

  30. Your domain model is in the protocols

  31. 1989

  32. Responsibility- Driven Design

  33. None
  34. http://www.flickr.com/photos/scania/2869194523/sizes/l/in/photostream/

  35. Designing Protocols

  36. Procedural code gets information then makes decisions. Object-oriented code tells

    objects to do things. — Alec Sharp, Smalltalk by Example Tell, don't ask
  37. Example: Passive Controller

  38. None
  39. None
  40. None
  41. None
  42. None
  43. None
  44. None
  45. None
  46. None
  47. Organization Creator Controller User Organization User Interface

  48. Organization Creator Controller User Organization User Interface Feed Writer ActivityFeed

  49. WDYT?

  50. Pattern Wankery?

  51. Snake Oil?

  52. Java?

  53. None
  54. Let's explore!

  55. References http://www.threeriversinstitute.org/blog/?p=338 http://www.growing-object-oriented-software.com/ http://pragprog.com/articles/tell-dont-ask http://alistair.cockburn.us/Hexagonal+architecture http://devblog.avdi.org/2012/03/15/now-available-objects-on-rails/ http://mattwynne.net/category/hexagonal-rails/ http://www.wirfs-brock.com/PDFs/How%20Designs%20Differ.pdf http://nccastaff.bournemouth.ac.uk/jmacey/CA1/Papers/Responsibility-Driven%20Design.pdf