$30 off During Our Annual Pro Sale. View Details »

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.

mattwynne

June 23, 2012
Tweet

More Decks by mattwynne

Other Decks in Programming

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. 1989

    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