Write business logic that scales.
Solid Process is where the business rules of a Ruby or Rails app go to stay legible. Each library does one job, composes with the rest, and keeps the same shape whether you're writing a single service or wiring up a whole domain.
As more of that code gets read and written by AI agents, the structure that keeps a process clear for a teammate is the same structure that keeps it cheap for an agent to reason about.
Make it
work;
Make itbetter;
Make iteven better;
Without throwing away what came before.
It is a Ruby/Rails library that encapsulates business logic into manageable processes. It simplifies writing, testing, maintaining, and evolving your code, so it stays clear and approachable as your application scales.
Write a process as a single object with typed input, an ordered set of steps, and a result. From that one shape you get:
- Composition
- Nested processes
- Database transactions
- Built-in instrumentation
- All without fighting Rails conventions
It's the evolution of u-case, with fewer compatibility constraints and everything learned from running it in production.
A general-purpose result object: Success(...) or Failure(...), with hooks and pattern matching for reacting to an outcome. It's how solid-process represents every result, and it stands on its own to bring Railway-Oriented Programming to any Ruby code.
Interface contracts in pure Ruby. Declare the boundary an object has to honor, wrap a concrete implementation in a checked proxy, and keep your ports and adapters honest, with no Rails in sight.
"Talk is cheap. Show me the code", as Linus Torvalds put it. So here are two repositories instead of an argument.
They are the same application built at many levels, from a fat controller all the way to ports and adapters. I built them because the loudest opinions in this space usually arrive with no working example attached: that Rails alone is always enough, or that you always need a hexagon around it. Read the diffs and weigh the cost for yourself.
The same app climbing across twelve branches, from simple service and form objects up to a full ports-and-adapters (hexagonal) build with solid-process. It shows what the gem buys at each step, and where stopping early is already a production-ready win.
The same Web and REST API app in eighteen versions, each one getting more out of plain MVC and the Rails Way, no gems required. Every version reports its lines of code and Rubycritic score, so a refactor's cost is a number, not a feeling. It is the baseline for how far convention alone carries you, and the idea keeps going, pushed further still, in Rails Whey.
A few rules shape the libraries:
- One library, one job.
solid-resultrepresents outcomes,solid-adaptersguards boundaries,solid-processorchestrates steps. Reach for only the part you need. - Build on Rails, don't reinvent it.
solid-processis built on ActiveModel and ActiveSupport on purpose, reusing Rails' own building blocks instead of reimplementing them. That's a deliberate break fromu-case, which stayed Rails-optional. - Readable as it scales. A process should be as easy to follow in year three as on day one, for whoever (or whatever) reads it next.
- Pragmatic, not dogmatic. Adopt it where it fits and leave the rest as vanilla Rails. The goal is the right tool for the job, not architecture for its own sake.
These libraries grew out of u-case and the μ-gems collection, an earlier set of small Ruby libraries with a functional heart. solid-process keeps that goal, folding in everything learned from years of use in production across many companies.
u-case is not going anywhere: its public API is frozen and stays supported, so apps that depend on it keep working untouched. solid-process is the place where the abstractions get rethought without that constraint. If you're happy with u-case, stay; if you want the next-generation ideas, they live here.
- 🌐 Website: https://solidprocess.dev
- 🎨 Brand assets: https://github.com/solid-process/the-assets
Each project ships under its own MIT license. Check the repo for details.