Part 1 (re: Architectural Decisions) I was recently asked about the architectural decisions we’ve made in our most recent Ruby on Rails project (an e-commerce platform for sports apparel decoration).
We decided to stay close to Rails’ conventions as much as possible. This allowed the team to build out the first features quickly. This is usually not a problem for short-term projects, but it becomes a maintenance burden after a year, because after a year the team is also concerned about supporting what they’ve built despite changes to team structure or project focus.
Project-specific conventions
In some areas where Ruby on Rails has no opinion, we’ve established our conventions:
- Using service classes (and using LightService)
- Using namespaces to partition functionality (e.g., Dealers, Admin, Checkouts)
- Avoiding the use of JavaScript-heavy frameworks (e.g., VueJS) in favor of Stimulus and HTML-over-the-wire (this was done pre-Hotwire)
- Prefer application events over ActiveRecord callbacks when triggering jobs
- Adopting Spree as the e-commerce engine instead of building from scratch
Conventions distilled into pattern
We also wanted to make it easy for a new developer to understand how a feature was built and where to make subsequent changes. Having these patterns in place and adopted across the entire codebase also helps the maintainers to troubleshoot issues two years after a feature has been deployed to production.
Nestor, WTF?!? 