Rails gives us great conventions for building an application, but what conventions should we use when we are building a whole system that encompasses multiple applications? How should we name things? What abstraction layers should we enforce?
The MX team has been building a distributed system composed of Rails applications for the last 3 years. We'll talk about failed ideas, conventions that have stood the test of time and some experiments that are underway.
Much of what makes Rails great is the set of conventions that it gives us. We get naming conventions, architecture conventions, testing conventions, etc. No project sticks to every convention strictly, but having a convention forces us to choose which parts of our application really need to be unconventional.
This is a talk about what conventions make sense at a layer of abstraction just above Rails. In a service oriented architecture (or any distributed system) conventions can benefit our design process, development process and team process in much the same way that conventions at the Rails layer can benefit us.
This talk is part experience report and part conjecture. I'll share the conventions that have stood the test of time for our team over the last 3 years and a few ideas of conventions that we are currently experimenting with.