Component Based Architecture at the Iron Yard
The SciMed team and the students at the The Iron Yard gathered together at the American Underground on June 22nd to hear developer, Emerson Huitt, give a fascinating talk about component based architecture in Rails. While Rails provides a structured MVC design, oftentimes it is simply not enough architecture for large projects. This is where component based architecture excels. Because Rails is so heavily dependent on object based design, the default MVC structure operates on many implicit dependencies. Working with components, which mirror objects in their ability to encapsulate data and behavior, gives you the flexibility to explicitly define dependencies between areas of the application, freeing yourself from the limits of the Rails defaults.
Isn't it a lot of trouble to use component based architecture when Rails already provides an architecture for you?
No! Rails already has support for components in the form of gems and engines. Isolating logically related portions of your application within gems allows you to define dependencies between portions of your code with ease. This approach also allows you to test the functionality of a component in isolation from the rest of the system.
How can this benefit you?
Excellent question! I'll give you four benefits.
You'll have a better understanding of the your system. Explicitly defining dependencies makes it much easier to understand the intent of each component of the system.
Collaboration is easier. Two developers working on different parts of the system are able to understand how their work will interact.
It's much easier to predict which parts of the system will be affected by a given change.
You'll have a greater confidence in your system. Thinking about higher level components forces developers to discuss architecture in depth. Testing portions of the code in isolation allows you to reason about where problems are with greater accuracy.