Rails is half of your application

It's been over a year since Obvious Architecture came out and over a year before that when Uncle Bob gave his talk on Ruby Midwest. People seem to just now be catching on.

I've gone really deep down the rabbit hole on these kind of highly decoupled design patterns in Obvious, clean architecture, functional programming, TDD and all of that and I realize now that Ruby is not the optimal language for this style of development and DHH and Rails' purpose is not the same purpose of clean architecture.

I go back and think about the original build a blog in Rails demos, which are great BTW, and I feel like Rails' strength is standing up an application quick and getting stuff done. Yes it can do TDD and clean architecture and all of that fun design stuff, but to be completely honest, it doesn't fit the community or the language as much as it should.

Ruby gives you a lot of amazing tools, but there are a lot of things that make clean architecture way nicer that you end up bolting on to Ruby. Stuff like immutability, type checking, and strong interfaces are not the norm in Rubyland. That is perfectly fine, but by the time you build all those tools, it's hard not to look at a language like Scala or Kotlin and see a lot of those things built in to the language along with a compiler and nice IDE support.

I love Ruby and I use it every day. I live in a Rails app most of the day and I've found ways to make to make the code beautiful, but fundamentally I don't think the Ruby community will ever truly get behind clean architecture. It really flies in the face of the reasons why most people use Ruby in the first place.

In my experience, projects written in frameworks like Rails an Django have a tendency to end up with business logic sprinkled everywhere:

    Persistence + Business <-> Frontend + Business

You end up with business logic in ORM code, POST validation, Javascript form validation...

You usually want:

    Persistence <-> Business <-> Frontend

That way you can extract a business API and be transparent whether it's making SQL queries, talking to a webservice, a file, or something else.

Another mistake IMHO is going crazy on OO and having, e.g., an `Order` object encapsulate everything like validation, persistence, reporting, serialization, etc... You end up with an object that retains so much state that it's hard to test. By coupling data and function you also end up in a corner trying to do bulk operations efficiently, falling into an awful idiom of iterating objects and calling a method on them, leading scalability issues with N*M queries, and so on. The testable/scalable route is following a functional approach and designing your business API from the start around functions that deal with sets and take all the necessary state as a parameter, or data structure that represents the current state.

I find it really interesting and awesome that Rails and PHP are both (at the same time) in the process of (re)discovering the architecture described in Evan's DDD and Fowler's PEAA.

What's old is new again! Rails has existed long enough to have a need (and a vocal chunk of the php community has matured enough) to think of apps architecture with a longer term in mind.

I think devs are seeing frameworks as a tool to implement an application instead of being the application itself (as originilly conceived before Rails revolutionized RAD).

Great!

Not sure I agree with the idea that `Rails == UI`. A lot of the time I'm trying to fight Rails on this as decoupling HTML means refactoring HTML which isn't fun.

I use Rails as a thing that controls boundaries, a glorified CGI really. It's a router, input sanitizer, and general plumbing that spurts out JSON every now and then. It's a mid-level wall in a fortress: server + OS deal with TCP, Rails + Rack handle HTTP, Rails handles raw user input, proxy objects handle Rails, the actual business logic handles proxy objects.

This is the only workflow that allows me and Rails to be long-term friends:

When a request comes in to the API (say, change password) the controller will sanitize and confirm presence of the right params and collect things like the current user. It'll then pass these off to a proxy object e.g. `CustomerPasswordUpdater.update!(user, new_pass)` which will validate length, entropy, etc and perform any necessary crypto. Then that data gets passed off to another proxy object which abstracts over ActiveRecord e.g. `UserPersister`. There's literally nothing inside the model itself. The core `Customer` object is nothing but a decorated window on the relevant data (accessed through unambiguous proxies e.g. `UserReader`, never directly through the model).

This may seem a bit framework-inside-a-framework but the result of this approach is that specific chunks of logic - your logic, the stuff you write on a whiteboard - is clearly identifiable in these small unambiguous classes.

The grand upshot is that I can plan my application on a piece of paper, write all my logic in plain old Ruby with plain old RSpec and plain old gems at breakneck speed, and there's no stupidity like tests hitting the DB or 40 minute test runs in sight.

Once all that's done wiring it up to Rails takes a day or two. At any point I could write a few new proxy objects and drop the whole thing in to Sinatra&Sequel/ Sinatra&Neo4j/ Sinatra&PStore/ Whatever&Whatever. At no point does the logic that defines and encapsulates the actual business problem that needed solved need to be touched.

We use an interactor pattern with organizers to keep domain logic dry and reusable. Skinny models and controllers. http://collectiveidea.com/blog/archives/2012/06/28/wheres-yo...

Don't restrict yourself to MVC. It's a phenomenal start to any given project but ultimately your going to have to do what real engineers do. Example, lets say I'm building a game. The underlying framework is object oriented and adheres to a type of MVC pattern to manage view states. We use a component entity system to manage game entities and logic. The same goes with Web stacks it's the framework, but not limited to the underlying pattern. Extend your domain logic out from the MVC. It's not rails job to do everything for you. I feel the developer is at fault more than rails. Buck up and break the pattern it's not beyond reason.

Half? More like 1/5th or even less. Ruby is the real horse power.