Fundamentals of Software Architecture

The problem I had a Rails codebase with a 730-line model and a 874-line controller. Code reviews kept surfacing the same vague complaint: too coupled. I could not name which violation to fix first or explain why one was worse than another.

The concept Richards and Ford give you a framework, not a checklist. Architecture characteristics as first-class design targets. Connascence as a coupling severity scale: static forms like name and algorithm are manageable, dynamic forms like execution order are dangerous. Fitness profiles that let you score one architecture style against another on the dimensions that actually matter for your context.

The decision I audited Synergym against every major concept. Named the implicit style (layered monolith), scored its fitness profile, and wrote the first three ADRs the codebase ever had. The coupling in User.rb finally had a name: connascence of meaning and connascence of algorithm. That is enough to know where to start.

Effect Three ADRs documented. One TypeScript spike shipped. One article published. The codebase did not change dramatically. What changed is that every structural decision now has a record and a reason. Full breakdown: Every Rails App Has an Architecture. Mine Just Didn't Know It Yet.

Trade-off The book is written with enterprise and distributed systems in mind. A solo Rails app sits at the opposite end of that spectrum. You do the translation yourself. Not every chapter maps cleanly to a five-table monolith, but the vocabulary is worth the effort.