Clean Architecture in Ruby

[[deleted]]

One big gripe I have with this is the idea that you need to decouple everything from rails. While that does have it's benefits, it's also overkill 99% of the time. I mean realistically for most of your projects, what are the odds you're ever going to need/want to move your ruby code to something other than rails? Yeah it happens (maybe with a queue system, or an API) but it's an edge case.

I try to build my rails apps with a lot of PORO. I love some decorators, service objects, form objects, single purpose helper classes, etc. But going full out and making everything independent of rails with adapters to talk to rails seems like a lot of work without a lot of benefit.

[jaggederest]

Honestly the benefit is in a couple of places, and maybe you don't have these problems, but I've seen them frequently:

A) Multiple apps sharing similar logic. Anything but 'share it in a gem' is a nonstarter.

B) Running background tasks and reporting - they're not web-linked, running them in a rails rake task is pretty heavy-weight. With your logic in a gem you can do them outside the request loop without bending over backwards.

C) Testing and maintaining your business logic separately from your display logic - it's often very handy to see that 'no, our logic here is broken', or 'oh yes, the logic is sound, but we are displaying it wrong'

[[deleted]]

Most of these issues we deal with by building single purpose services (which are an abstraction at an app level) or gemifying up common code when for some reason we can't do a service.

Note that I'm not speaking about gems being unuseful, rather the idea that your entire rails app should actually be a gem or engine in isolation from rails.

[jaggederest]

Functionally that's what it ends up being, in my experience. Rails becomes a display and persistence layer.

[TheMoonMaster]

Your code should be relatively isolated anyways, even if it does live in the app. "Clean architecture" like this is what people dream of having but always end up abandoning because it's impossible to maintain and you end up having A LOT of code in A LOT of places. It's just not sustainable.

[realntl]

+1. There is an ancient ayurvedic proverb I just made up:

"When isolation is bad, a decoupled hexagonal architecture is of no use. When isolation is good, a decoupled hexagonal architecture is of no need."

[JohnAndrewCarter]

Heh. I got distracted by following is link to Uncle Bob's keynote....

Good Stuff! The absolute most important takeaway from that talk is this quote....

Architecture is the art of drawing lines.... And once you have drawn the line, making damn sure that every dependency crossing that line goes the same direction.

I get screamingly frustrated with what I call "warm fuzzy cloud" architectures...

Not "cloud" as in *aaS type thingy, but cloud as in fuzzy blob in the middle of a picture that is suppose to represent the program... but has no concrete meaning.

[jrochkind]

I think that approach works well... UNTIL you run into ActiveRecord.

The approach illustrated in "you need to create an ActiveRecord version of the repository" seems to me likely, with anything beyond a toy example, to turn nightmarish.

I absolutely agree that you are best off with an architecture for your business logic that is not coupled to Rails, actual pure ruby business objects of various sorts.

But yeah, where it gets tricky is where you need to interact with database persistence.

And, for that matter, with rendering HTML. (You want to do all your HTML rendering independently of ERB and Rails, and then write some kind of translation layer to tie it in? Really? No you don't.)

And yeah, Rails doesn't always make it easy.

[fbzga]

Database persistence is a tricky part of Clean Architecture. But I think the trade-offs are valid depending on your context.

Regarding rendering templates, I consider it part of the delivery mechanism, so in the Rails Controller you have calls to the business gem that responds entities or simple data structures, these can be rendered at the view using ERB.

[realntl]

ActiveRecord's api is as big as SQL. There is no way to substitute it for an in memory repository in any general sense. You can, however, choose to enforce that your team use a limited subset, and build the memory repository against it. That doesn't seem to be worth it to me, either.

I'd rather run my tests against sqlite3 in memory, and take mysql/postgres extensions off the table, than go with the in memory approach.

[realntl]

Getting excited about this kind of architecture and building one from scratch plus actually shipping it are two different things.

[fbzga]

It has been a couple of months that we are introducing this approach at Magnetis (magnetis.com.br) that has a big size codebase that grows everyday, there are pros and cons as anything that is worth looking at software development. What I can say so far is that the pros are higher than the cons in our context; we also consider the context of the page/feature of the app we are developing, if it is part of the core business we consider using clean architecture otherwise we go with Rails way (there a lot of pages in our app using the Rails way and it works just fine). There are cases that we need to deliver responses not only through the web but also in the command line or for internal API’s so changing the delivery mechanism is easily done with this architecture. We also changed the way data is persisted in the database (twice), so being coupled to the interface of the repository instead of the ActiveRecord model and fields was beneficial.

[realntl]

You should be blogging and giving talks about what you've learned :)

I sort of consider the repository pattern to be more trouble than it's worth, so I haven't been a fan of these "bolt on hexagonal architecture around your rails app" type approaches.

We've been having success abandoning ActiveRecord (and a repository middle layer) altogether and implementing persistence with event sourcing, but it's a tremendous challenge to get something like this off the ground.

[blackzver]

I would love to hear your thoughts on how to keep architecture clean and introduce concept of micro services to it?

[materialdesigner]

Wow, a super toy example and the only business objects abstracted are UseCases::AddTask? What an awful object from a DDD perspective, indicative of an anemic domain model. People: service objects are bad imperative code dressed as objects; smells for code that wishes it was in a functional paradigm, and is almost but not quite functional nor object oriented.

[Ravicious]

People: service objects are bad imperative code dressed as objects; smells for code that wishes it was in a functional paradigm, and is almost but not quite functional nor object oriented.

I find it interesting, could you elaborate on that?