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.

Transcript

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

   View Slide

2. View Slide

3. View Slide

4. View Slide

5. View Slide

6. Caveat
   

   View Slide

7. View Slide

8. View Slide

9. and then...
   

   View Slide

10. View Slide

11. Why?
    

    View Slide

12. View Slide

13. Connected
    

    View Slide

14. Modular
    

    View Slide

15. View Slide

16. View Slide

17. Modular,
    in the large
    

    View Slide

18. View Slide

19. What does
    it do?
    

    View Slide

20. Web UI
    API
    Project
    Topic
    Publisher
    User
    Membership
    

    View Slide

21. No,
    What does it
    do?
    

    View Slide

22. Metaphor
    

    View Slide

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

    View Slide

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

    View Slide

25. Modular,
    in the small
    

    View Slide

26. Protocols
    

    View Slide

27. View Slide

28. Your domain model is not in your
    classes, it's in the communication
    patterns between the objects at
    runtime.
    — Steve Freeman & Nat Price
    

    View Slide

29. Your domain
    model is not
    where you think
    it is
    

    View Slide

30. Your domain
    model is in
    the protocols
    

    View Slide

31. View Slide

32. Responsibility-
    Driven Design
    

    View Slide

33. View Slide

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

    View Slide

35. Designing
    Protocols
    

    View Slide

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
    

    View Slide

37. Example:
    Passive Controller
    

    View Slide

38. View Slide

39. View Slide

40. View Slide

41. View Slide

42. View Slide

43. View Slide

44. View Slide

45. View Slide

46. View Slide

47. Organization
    Creator
    Controller
    User
    Organization
    User
    Interface
    

    View Slide

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

    View Slide

49. WDYT?
    

    View Slide

50. Pattern
    Wankery?
    

    View Slide

51. Snake Oil?
    

    View Slide

52. Java?
    

    View Slide

53. View Slide

54. Let's explore!
    

    View Slide

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
    

    View Slide