Wednesday, September 02, 2015

Top Down Vertical Slice Risk Oriented Integration

How can you avoid developing a brittle Rails app?


Submarine Pattern in Rails


1. Write a small Rails app for one function.
2. Get it working.
3. Extract the re-usable code from the Rails app into a Micro Gem.
4. Make sure the dependency direction is from the Rails app to the Micro Gem. If you have dependency that goes in the other direction to the Rails framework, you will have headaches during Rails upgrade. It will defeat the purpose, because you will end up with Spagetti code.
5. Refactor the Rails app to use the Micro gem.

Repeat the process for flushing out the details of other features. Only the features with high risk are split into a small Rails app for each of the high risk feature. The main Rails app uses the Micro Gems to delegate the tasks.

In my project, I have extracted dependencies that are due to third-party API such as:

1. Amazon S3
2. Paypal Express Checkout
3. Stripe Subscription API

to mention a few.  These are not just risky parts of the system, they also have their own release schedule. We don't want to rely on a third party release schedule. We can upgrade the Micro Gems as per our schedule and use the newer version of our gems in the project. We also contain any problems that may arise by isolating them into it's own Micro Gem that provides a useful functionality. I also don't need the flexibility of switching one of these third party API with their alternatives.

I have also extracted gems for functionality that is run as the background jobs when some event happens in the Rails app.

Reference


Code Complete 2 by Steve McConnell