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

Abstracting your Application away from Rails

Myles Megyesi
February 24, 2012
680

Abstracting your Application away from Rails

Ruby on Rails makes building web applications extremely easy. All you need is an idea, the Rails Guides, and a little programming experience and you can have an application up and running in no time. However, time after time we have seen businesses paralyzed by applications built in this manner. As the business grows, the application must grow as well to accommodate the changing needs of the business. However, as a result of the coupling to Rails, the growing application becomes rigid (hard to change), fragile (easy to break), and immobile (hard to reuse). Eventually, development will slow to a halt and the business will have no room to grow. In this talk I discuss how abstracting your application away from Rails will allow you to continuously improve the application without bringing development to a halt. I will also analyze the costs and the benefits of this abstraction, as well as a case study on how to do it.

Myles Megyesi

February 24, 2012
Tweet

Transcript

  1. • Rigid (hard to change) • Fragile (easy to break)

    • Immobile (hard to reuse) However...
  2. Symptoms • Rigid • Fragile • Immobile • Viscous •

    Needless Complexity • Needless Repetition • Opacity
  3. The design of an application is an abstract construct that

    has to do with the overall shape and structure of the program as well as the detailed shape and structure of each module, class and method. [Robert Martin, Agile Software Development: Principles Patterns and Practices, 87]
  4. Designs start to degrade because business requirements change in ways

    that the initial design did not anticipate. Often, these changes need to be made quickly, and they may be made by developers who are not familiar with the original design philosophy. [Martin 89]
  5. If we want our Rails apps to be successful, we

    need to have extensible designs.
  6. Class Client Client Client Client Client Client Client Client Client

    Client Client Client Client Client Client Client Client Client Client Client
  7. Controllers Controllers Controllers Controllers Controllers Controllers Models Business Rule Business

    Rule Business Rule Business Rule Business Rule Business Rule Models Business Rule Business Rule Business Rule Business Rule Business Rule Business Rule Models Business Rule Business Rule Business Rule Business Rule Business Rule Business Rule Models Business Rule Business Rule Business Rule Business Rule Business Rule Business Rule Models Business Rule Business Rule Business Rule Business Rule Business Rule Business Rule Models Views Views Views Views Views Views
  8. Controllers Controllers Controllers Controllers Controllers Controllers Views Views Views Views

    Views Views Abstraction Models Business Rule Business Rule Business Rule Business Rule Business Rule Business Rule Models Business Rule Business Rule Business Rule Business Rule Business Rule Business Rule Models Business Rule Business Rule Business Rule Business Rule Business Rule Business Rule Models Business Rule Business Rule Business Rule Business Rule Business Rule Business Rule Models Business Rule Business Rule Business Rule Business Rule Business Rule Business Rule Business Rules