[halostatue]

I've only been involved in a couple of Rails projects (at least since the wedding list management app I wrote for my own wedding back in the v1 days), I'm in complete agreement with David.

And honestly, Rails already has something that works beautifully for an “interactor” extraction. It's called ActiveModel. Add a bit of other code (include ActiveModel::ForbiddenAttributesProtection, ActiveModel::Validations::Callbacks, and ActiveModel::SerializerSupport; extend ActiveModel::Naming) and you've got an object that acts like an ActiveRecord object but orchestrates changes across multiple models in a clean, constructive way—without introducing an entirely different way of working with your code.

I've done this at both places I've been doing Rails and it works at both cleaning up the models it orchestrates and keeping the business logic in the places where it belongs. I'm working actively to get rid of some of the Rails Fads that have come through and wreaked havoc on the current codebase (we've got Presenters and Commands and all sorts of other stuff that is just making the code harder to understand with little value).

There's a million ways to skin this particular cat, and claiming that “adult” Rails needs this particular gem or that particular way of writing code says a lot more about the person claiming it than the people who aren't following that particular fad.

[dasil003]

> And honestly, Rails already has something that works beautifully for an “interactor” extraction. It's called ActiveModel.

The thing which Rails and DHH offer no guidance whatsoever is the separation of persistence from the domain model. The Active Record pattern is itself a conflation of those two things, so this is an opinionated choice, and I respect it as a sane default for a wide variety of applications. It works perfectly fine up to a certain scale but when the business logic reaches a certain complexity and the persistence logic reaches a certain complexity then it makes sense to separate them. A lot of proposed solutions might be overkill, but keep in mind that DHH and the company formerly known as 37signals specialize in minimalist software, so they combat this complexity from the UX down rather than conceiving architectures to support it. I agree with this philosophy insomuch as all else being equal, simpler is better, but the problem is that some applications are necessarily more complex than Basecamp, and sometimes we need more than what Rails provides out of the box. Convincing DHH of this is pointless because he doesn't have to deal with it and he has no incentive to understand anyone else's pain in this regard.

[halostatue]

Here's the thing, though: Rails purposefully doesn't provide more than the minimum. I disagree with DHH on many things (ActiveRecord’s persistence model being based on MySQL misfeatures has been one of my biggest frustrations with Rails since he introduced it at a RubyConf where we both presented), but he's right that this sort of thing doesn't belong in Rails.

Everyone[1] needs a persistence layer and domain objects. That ActiveRecord is both ActiveModel and persistence is neither here nor there—and Rails 3 did a lot to making it possible to separate ActiveModel (domain object behaviour) and ActiveRecord (persistence layer behaviour) in a logical perspective so you can choose to persist differently than ActiveRecord does. Everyone needs some kind of controller. Everyone needs some kind of presentation layer. Aside from providing sane defaults for all of this, Rails doesn't try to dictate how your application is built.

The “more complex” architecture required for your application is unlikely to be a good fit for my application’s “more complex” architecture. For Rails to anoint one particular “more complex” architecture…is to fail anyone else who doesn’t need that architecture or would need something different. If you want to promote a particular type of architecture, there are ways: write an Engine; include generators. Give people guidance. Tell people why they want to use your particular architecture, but also tell them why they shouldn’t use it. If a lot of people need it, they will adopt it. Like Rspec. Like cucumber. Like ActiveModel::Serializers.

And, honestly, consider whether you really need your “more complex“ architecture or whether you can combat it the same way that Basecamp does. We're doing that with our product team, trying to find features we can remove and reimplement later when we really need them. Ours is a fairly mature product, so it's hard—but it's happening.

[1] For some large subset of everyone. Anyone who is reaching for something like Rails, Django, etc. needs some sort of persistence layer. Anyone who needs to store data needs that. Everyone needs domain objects.

[dasil003]

Where did I say Rails should provide this? My point was primarily that attempting to convince DHH of your architectural choices is sisyphean and ultimately pointless since he has crafted a nice bubble for himself where he doesn't have to be exposed to architectures or complexities that he finds distasteful.

[halostatue]

> The thing which Rails and DHH offer no guidance whatsoever is the separation of persistence from the domain model.

This seems to suggest you were looking for guidance or sane defaults for this. If that's not what you intended it to mean, I'm sorry for misreading it.

[dasil003]

Your interpretation is not what I intended but neither is it completely unfair.

I am looking for guidance (or rather good discussion and ideas) about how to address this issue for larger Rails apps, just not from Rails or DHH. I don't think it's Rails' place to do this since I don't really think a one-size-fits-all approach is right and it sort of tramples over the core philosophy of ActiveRecord which I believe is a useful default. On the other hand I don't buy into DHH's philosophy that its all astronaut architecture either.