DEV Community: Mark Harbison

Composability Over Coupling: Evolving Authorization in Rails

Mark Harbison — Wed, 04 Mar 2026 10:40:52 +0000

Authorization feels simple in the early stages of a Rails application.

You define a few roles.
You write some policy methods.
You add a handful of conditional checks.

It works.

In year one, that's usually enough.

The tension appears later.

Features expand. Roles multiply. Exceptions accumulate. A simple "admin vs user" distinction becomes a matrix of capabilities. What started as a few clean policy methods begins to encode assumptions about how permissions are stored and assigned.

And that's where the real problem surfaces.

Not complexity.

Coupling.

When your permission model changes, how much of your policy layer needs to change with it?

If the answer is "a lot", then the system isn't just complex. It's entangled.

In long-lived Rails applications, authorization strategies evolve. Direct permissions become group-based. Groups gain hierarchy. Multi-tenant boundaries appear. Auditing requirements emerge. The persistence model shifts to accommodate new realities.

Your policies shouldn't need to be rewritten every time that happens.

Authorization logic will grow. That's normal.

What matters is whether it grows inside clear boundaries - or across them.

The Hidden Coupling in Most Rails Authorization

In many Rails applications, authorization logic begins its life inside policy methods.

A policy might check a role directly:

def update?
 user.admin? || user.manager?
end

Or it may reach into a permissions table:

def destroy?
 user.permissions.exists?(name: "employees.destroy")
end

There's nothing inherently wrong with either approach. They're straightforward. They're readable. They solve the immediate problem.

The issue is structural.

In these examples, the policy method is doing more than expressing intent. It's also deciding how that intent is evaluated. It knows where permissions live. It knows how they're queried. It often knows how roles are represented.

Orchestration and decision logic become intertwined.

Over time, this pattern scales in ways that aren't immediately obvious. A few direct checks become dozens. Slight variations appear between policies. Edge cases introduce conditionals that reference specific tables or associations. The policy layer starts to mirror the persistence layer.

At that point, a change to the permission model isn't isolated. It ripples outward.

If you move from direct permissions to group-based RBAC, policy methods change.
If you introduce tenant scoping, policy methods change.
If you refactor roles into something more granular, policy methods change.

The policies were meant to answer a simple question: "Is this action allowed?"

Instead, they've become tightly coupled to how that answer is computed.

This isn't a critique of a specific authorization strategy. The problem is structure, repeatability, and maintainability.

The issue isn't RBAC. It's entanglement.

Principle 1: Authorization Strategies Should Be Replaceable

To untangle authorization, we need to separate three concerns that are often collapsed into one.

First, there is the policy engine. This is the orchestration layer. It decides when authorization is evaluated and which policy method is responsible for a given controller action.

Second, there is the authorization strategy. This is the decision logic. It answers the question: given a user and a context, is this allowed?

Third, there is the persistence model. This is a domain concern. It defines how roles, groups, permissions, and relationships are stored and associated.

These are not the same responsibility.

In many systems, they drift together over time. The policy method calls into a role check that assumes a specific table structure. The role check assumes a particular association model. The persistence layer becomes implicitly coupled to the policy surface.

That coupling rarely hurts in year one.

It becomes visible in year three.

Direct permissions become group-based.
Flat groups acquire hierarchy.
Single-tenant assumptions give way to tenant scoping.
Static roles evolve into dynamic, feature-level permissions.

None of these shifts are unusual. They're a sign that the system is growing.

But if your policies are written against a specific storage model, every structural change forces a policy rewrite. The orchestration layer becomes brittle because it knows too much.

That's unnecessary.

Policies should express intent.
Strategies should evaluate that intent.
The persistence model should serve the domain.

If those boundaries are respected, the authorization strategy can evolve without destabilising the policy surface.

Policies should not care how permissions are stored.

They should care only that a decision can be made.

Principle 2: Policies Should Orchestrate. Rules Should Decide.

If authorization strategies are meant to be replaceable, the structure of the policy layer has to support that.

This leads to a second principle: Policies should orchestrate. Rules should decide.

A policy sits at the controller boundary. Its responsibility is to map an action to an authorization outcome. It expresses intent.

When a controller calls update, the policy answers a single question: is this action allowed?

It shouldn't need to know how that answer is computed.

Instead, the policy should compose one or more rule objects - small, focused units of decision logic.

A rule encapsulates the strategy.
It receives the user, the context, and any options.
It returns a boolean.

Conceptually, a policy method becomes something like this:

authorized?([PermissionPolicyRule], permission: "employees.read")

The policy declares the required capability.

The rule determines whether the user satisfies it.

That separation is subtle, but it changes the system's behaviour over time.

The policy remains stable because it expresses intent at the level of the application. "This action requires employees.read." That statement doesn't change just because your group model changes.

The rule encapsulates the strategy. Today it might query direct permissions. Tomorrow it might traverse hierarchical groups. In a multi-tenant system, it might apply scoping logic. The policy does not need to know.

The persistence layer becomes an implementation detail of the rule.
This is what composability looks like in practice. Policies compose rules. Rules encapsulate strategies. Strategies rely on the domain model.

Each layer has a boundary.

When those boundaries are respected, authorization logic can grow without spreading across the system.

Demonstrating the Separation

This separation wasn't an abstract exercise.

It's the architectural pattern I wanted when building long-lived Rails systems.

I wanted a policy layer that stayed stable as the application evolved. I wanted authorization strategies that could change without forcing a rewrite of every policy method. And I didn't want the core engine to dictate how permissions were stored.

That's the motivation behind AccessForge.

AccessForge handles orchestration. It resolves policies from controllers. It maps actions to predicate methods. It provides a small surface for composing rule objects.

It does not dictate how your application makes authorization decisions. It ships with two default rules — always open and always closed. The rest is left to you. You provide rule classes based on your own domain model.

The strategy layer can then be implemented independently.

This is where AccessForge::Permissions fits. It's the first official extension - a permission-based rule built on top of the core engine.

The contract is deliberately minimal: If user.permissions exists, a decision can be evaluated.

That’s it.

Permissions may be assigned directly to users.
They may be granted through groups.
Groups may be hierarchical.
Permissions may carry metadata or tenant scoping.

The rule does not enforce a structure. It relies on a boundary.

If the persistence model evolves, the rule can evolve with it.
If a different authorization strategy is required, a different rule can replace it.
The policies remain unchanged.

This isn't abstraction for its own sake.

It's about keeping orchestration stable while allowing strategy and persistence to adapt to the domain.

Why Composability Beats Coupling

The distinction here isn't about elegance. It's about system properties.

Composability is not a stylistic preference. It's an architectural characteristic.

When rules are small and focused, they become composable. A policy can rely on a single rule. It can combine multiple rules. It can layer contextual checks without embedding storage assumptions.

Policies compose rules.
Rules encapsulate strategies.
Strategies depend on the domain model.

Each layer has a clear responsibility.

Because of that separation, strategies can evolve independently. A permission rule can change its internal query logic. It can introduce tenant scoping. It can traverse hierarchical group structures. It can even be replaced entirely.

The policy surface does not need to change.

Contrast that with coupling.

If a policy method directly references user.admin?, it is bound to a specific role model. If permission queries are embedded inside multiple policy methods, logic becomes duplicated. When the persistence structure changes, those assumptions must be hunted down and rewritten.

The system resists change because its boundaries are unclear.

This is where many Rails applications begin to accumulate accidental complexity. Not because the framework is limited, but because structural decisions were deferred.

Flexibility does not come from fewer boundaries.

It comes from well-defined ones.

When policies orchestrate and rules decide, the system gains a stable surface and a flexible interior. Authorization can grow in sophistication without spreading across the application.

Composability over coupling is not an aesthetic choice.

It's a way to keep long-lived systems evolvable.

What This Means in Year Three

In the early stages of a product, authorization feels contained.

By year three, it rarely is.

Features expand. Capabilities become more granular. What was once a single "manage employees" permission becomes read, write, export, approve, and archive. Different customer tiers require different access levels. Enterprise clients ask for custom role configurations.

In a SaaS environment, tenant boundaries become stricter. Data isolation requirements increase. Audit trails become mandatory. Internal teams grow, and multiple developers begin touching the authorization layer.

At that point, authorization is no longer a small concern. It's part of the system's core integrity.

If policies are tightly coupled to a specific role model or storage structure, each new requirement increases risk. Changes feel invasive. Refactors feel dangerous. Work slows down because the boundaries are unclear.

But if orchestration, strategy, and persistence are properly separated, growth becomes more predictable.

New permission structures can be introduced without destabilising policy definitions. Tenant scoping can be added inside rules without rewriting controllers. Audit logic can evolve alongside the strategy layer.

The surface remains stable while the interior adapts.

That stability is not about purity. It's about risk reduction.

Long-lived systems accumulate complexity. That's inevitable.

The goal is to ensure that complexity accumulates behind boundaries, not across them.

Authorization doesn't need to be clever.
It needs to remain evolvable.

That's the design goal behind AccessForge and its first extension.
Not cleverness.
Replaceability.

Where Should Analytics Logic Live in a Long-Lived Rails App?

Mark Harbison — Sat, 07 Feb 2026 17:34:07 +0000

The problem as it appears over time

Analytics is rarely a problem in the early life of a Rails application.

At first, it’s a query in a controller. Then a bit of aggregation in a service. Maybe a chart that embeds some SQL because it was faster at the time. Nothing feels wrong - in fact, it often feels flexible. You can answer new questions quickly, and the code is close to where it’s used.

As the application grows, teams often try to improve things by introducing structure. A PORO per chart appears. Each report gets its own class. Logic moves out of controllers and into “analytics objects” that feel more intentional and easier to test.

This helps - briefly.

Over time, these objects begin to mirror the same underlying problems. Queries are duplicated with small variations. Filtering and aggregation logic diverge subtly between charts. Business rules become scattered across multiple classes with no shared vocabulary. The system looks organised, but the relationships between analytics concepts remain implicit.

In long-lived systems, this becomes risky.

Analytics code turns into something teams are hesitant to touch - not because it’s inherently complex, but because its structure makes the impact of change hard to reason about. Onboarding slows down. Small reporting changes feel larger than they should. What once felt flexible now feels fragile.

The issue isn’t that analytics exists. It’s that, in many Rails applications, it never gets a clear architectural home.

Why This Becomes Dangerous in Long-Lived Systems

In a long-lived Rails application, analytics rarely breaks loudly. Instead, it degrades quietly.

As analytics logic spreads across controllers, services, and chart-specific POROs, the system accumulates assumptions that aren’t written down anywhere. Filters behave slightly differently depending on where they’re applied. Aggregations are re-implemented with small inconsistencies. Over time, analytics becomes less a coherent part of the system and more a collection of loosely related behaviours.

The real cost shows up when something needs to change.

A new business question sounds simple, but requires touching multiple classes. A small tweak to a report risks breaking another chart that happens to reuse the same query in a different form. Developers become cautious - not because the change is difficult, but because the blast radius is unclear.

This uncertainty increases cognitive load. New team members have to learn not just how analytics works, but where it might be hiding. Context lives in people’s heads rather than in the structure of the system. Analytics slowly turns into “that part of the codebase” that only a few people feel comfortable modifying.

Ironically, many of these systems were built to be flexible.

But flexibility without clear boundaries tends to age poorly. What once allowed rapid iteration now creates hesitation, duplication, and accidental coupling. The system hasn’t become rigid - it has become fragile.

In practice, this often leads teams to avoid improving analytics altogether, or to work around existing structures instead of fixing them. At that point, the problem is no longer about charts or reports. It’s about architecture.

The Core Question

At this point, it’s tempting to reach for tools.

A new reporting library. A dashboard builder. A BI layer. Something that promises to “solve analytics” by adding capabilities on top of what already exists.

But the problems described above aren’t really about missing features.

They’re about ownership, boundaries, and structure.

The question isn’t how to build charts faster, or how to write more expressive queries. It’s a more fundamental design question:

Where should analytics logic live in a Rails application that’s expected to evolve over time?

Not as an implementation detail, and not as a collection of convenience methods - but as a part of the system with clear responsibilities and a clear place to live.

This isn’t a question about frontends or visualisation libraries. It’s not even a question about SQL versus ActiveRecord. Those decisions matter, but they sit downstream of a more basic concern: how analytics fits into the overall shape of the application.

Until that question is answered explicitly, analytics tends to remain incidental. It exists everywhere and nowhere at the same time. And in long-lived systems, that ambiguity becomes expensive.

A Different Way to Think About Analytics

If analytics is going to survive in a long-lived Rails application, it needs to stop being treated as a side effect of querying data.

It needs a shape.

One useful way to think about analytics is to separate it into a small number of distinct responsibilities - each with a clear purpose and a clear place to live.

At a high level, analytics work usually answers four different questions:

What data exists and is available for analysis?
Where does that data come from?
How is it queried, filtered, and aggregated?
How is it presented or consumed?

In many Rails applications, these concerns are collapsed into one place - often a controller action, a service object, or a PORO created “just for this chart.” That collapse is what makes analytics hard to reason about and harder to change.

Instead, imagine treating each of these concerns explicitly.

Separate the What from the How

The first shift is conceptual.

There is a difference between describing a dataset and querying it.

A dataset answers questions like:

What does this data represent?
What is it called in the domain?
Is it stable enough for charts, reports, or dashboards to depend on?

This description changes far less frequently than the queries built on top of it.

By naming and modelling datasets explicitly, you give analytics a stable anchor - something other parts of the system can reference without knowing how the data is fetched or calculated.

Make Data Sources Explicit

Next, separate where the data comes from from everything else.

Sometimes data comes from ActiveRecord models.
Sometimes from database views.
Sometimes from external APIs.
Sometimes from computed or in-memory sources.

In many codebases, this distinction is implicit and scattered. The source is “whatever the query happens to hit.”

Making data sources explicit - even when they’re just thin wrappers around existing models - creates a boundary. It gives you a place to say: this is the authoritative source for this analytical data.

That boundary is what allows analytics logic to evolve without constantly rewriting consumers.

Treat Querying as a Strategy, Not an Accident

Filtering, grouping, and aggregation are not incidental details. They’re behaviour.

When query logic is embedded directly inside controllers, services, or chart POROs, it becomes tightly coupled to its immediate use case. Reuse is accidental. Testing is awkward. Changes ripple unpredictably.

When querying logic has no explicit home, it still exists - it is just harder to see and harder to change.

Treating querying as a strategy - something that can vary independently - makes it possible to support different data sources, different querying mechanisms, and different performance trade-offs without reshaping the entire system.

This doesn’t mean abstracting everything behind clever interfaces. It means giving querying logic a clear role and a clear boundary.

Let Presentation Be the Last Step

Finally, presentation should consume analytics - not define it.

Charts, reports, and dashboards are views over analytics data. They should describe what they want (grouping, measures, filters, labels), not how the data is fetched or calculated.

When presentation concerns are kept at the edge, analytics becomes easier to test, easier to reuse, and easier to expose through different frontends - whether that’s a charting library, an admin UI, or an API.

Taken together, this model does something important:

It turns analytics from scattered behaviour into a small, explicit subsystem with its own vocabulary and boundaries.

Not heavier.
Not more abstract.
Just clearer.

This is usually where teams reach for structure - but not yet for architecture.

The “One PORO per Chart” Pattern - and Why It Breaks Down

A very common response to messy analytics code is to “clean it up” by introducing Plain Old Ruby Objects.

You end up with things like:

SalesByRegionChart
ActiveUsersOverTime
RevenuePerCustomerReport

Each class encapsulates the query, the aggregation, and the formatting needed for a single chart or report. Compared to SQL in controllers, this feels like a big improvement.

And to be fair - it often is an improvement.

This pattern usually appears when a team cares about code quality but doesn’t yet have a shared mental model for analytics as a system. POROs are familiar, flexible, and easy to introduce incrementally.

But over time, cracks start to appear.

Why It Feels Right at First

The one-PORO-per-chart approach works initially because:

Each chart has a clear owner in the codebase
Logic is no longer embedded in controllers
Queries are testable in isolation
Naming things feels like progress

For a while, analytics feels under control.

The problem isn’t that this pattern is wrong. The problem is that it doesn’t scale with the questions the business starts asking.

Where the Pattern Starts to Strain

As analytics grows, you start to see:

Slight variations of the same query copied across multiple POROs
The same filters implemented in subtly different ways
Aggregation logic drifting over time
Formatting concerns leaking into query objects
No single place to answer: “What analytics datasets does this system actually have?”

At this point, change becomes risky.

A small tweak to a definition - say, what “active user” means - requires hunting through multiple classes, each tightly coupled to its own presentation needs.

The code is organised, but the system is not.

The Hidden Cost: No Stable Analytics Vocabulary

Perhaps the biggest limitation of this pattern is that it never establishes a stable vocabulary for analytics.

Each chart PORO defines its own implicit dataset.
Each report re-describes what data it cares about.
Nothing is persisted, named, or shared at the domain level.

That makes it difficult to:

Reuse analytics across charts and reports
Expose analytics through admin tools or APIs
Version or migrate analytics definitions
Reason about analytics independently of the UI

The code answers how to build this chart, but not what analytics capabilities the system provides.

When POROs Stop Being Enough

Eventually, teams hit a point where:

Analytics needs to be configurable, not hard-coded
Non-developers need visibility into what exists
Frontends want structured data, not bespoke hashes
Analytics logic must survive refactors and rewrites

At that point, adding another PORO doesn’t really solve the problem. It just adds another place where knowledge lives.

What’s missing isn’t another class - it’s a clearer separation of responsibilities and a more explicit model for analytics itself.

Treating Analytics as a First-Class Domain

Long-lived Rails applications tend to stabilise around a few core domains.

We invest time modelling things like:

users
accounts
permissions
billing
workflows

We give them names, persistence, constraints, and clear ownership.

Analytics, by contrast, is often treated as something derived - important, but secondary. It lives in queries, helpers, or one-off objects because it’s “just reporting.”

But analytics isn’t incidental.

Analytics encodes how the business understands itself.

Definitions like active user, conversion, or revenue are not implementation details. They are business concepts, and they change over time. When those concepts aren’t modelled explicitly, they drift - silently and dangerously.

What First-Class Actually Means

Treating analytics as a first-class domain doesn’t mean building a BI tool inside Rails.

It means a few concrete things:

Analytics concepts have names
Those names refer to persisted definitions
Queries are built from those definitions, not the other way around
Presentation is a consumer, not an owner

In other words, analytics becomes something the application knows about, not just something it happens to compute.

Stability Enables Change

This may sound counterintuitive, but making analytics more explicit usually makes systems more flexible.

When datasets are named and stable:

charts can change without redefining data
reports can evolve without duplicating logic
performance strategies can be swapped without touching consumers
definitions can be versioned instead of rewritten

The system gains leverage because fewer parts are responsible for knowing everything.

A Familiar Rails Pattern, Applied Consistently

None of this is foreign to Rails developers.

We already do this elsewhere:

Controllers don’t own business rules
Views don’t own persistence
Models don’t own presentation

Analytics just hasn’t traditionally been given the same treatment.

Once you apply the same architectural discipline - clear responsibilities, explicit boundaries, stable concepts - analytics stops feeling like a mess of special cases and starts behaving like part of the system.

Analytics That Survives the Second Rewrite

Most Rails applications can ship analytics.

The harder problem is keeping analytics correct, understandable, and changeable once the application has been around for a few years.

That’s usually when teams discover that:

definitions have drifted
logic is duplicated in subtle ways
no one is quite sure which chart is “right”
changes feel risky even when they shouldn’t be

These problems aren’t caused by a lack of tooling. They’re caused by analytics never being given a clear place in the architecture.

When analytics is treated as a first-class domain - with explicit concepts, stable definitions, and clear boundaries - it becomes easier to reason about and safer to evolve. Not because it’s abstracted, but because it’s named.

This way of thinking is what led me to build AnalyticsPlane - a framework designed to make these boundaries explicit and durable in real Rails applications.

If you’ve felt the pain of analytics code that grew organically and then hardened into something brittle, you’re not alone. And you don’t need to solve it all at once.

Start by asking a simpler question: Where should analytics logic live in a long-lived Rails app?

Sometimes, the answer isn’t “a better query” - it’s a better place for the concept to exist.

A Final Thought

None of this is intended as a universal solution. It’s one way of giving analytics a clearer place in applications that are expected to evolve over time.

I’m interested in how others think about these trade-offs, particularly in long-lived Rails systems:

Where does this kind of explicit structure start to feel like over-engineering in your experience?
At what point in a Rails app’s life would you expect these boundaries to become worth the cost?
What analytics responsibilities would you be most tempted to collapse - and why?

Decorator Dryer: Keeping Your Ruby On Rails Decorators DRY

Mark Harbison — Sun, 14 Jan 2024 15:26:46 +0000

As Ruby on Rails developers, we often find ourselves striving for clean, concise, and maintainable code. The "Don't Repeat Yourself" (DRY) principle is at the core of our coding ethos, yet when it comes to decorator classes, we sometimes encounter the inevitable build-up of repetitive code. This contradiction can make maintaining and updating decorators a challenging task.

Decorators play a crucial role in Rails applications by encapsulating presentation logic, but as our codebase grows, so does the list of attributes that we need our decorators to transform. In our pursuit of cleaner code, leveraging tools like Draper has been a game-changer. Draper simplifies decorator implementation and enhances the maintainability of our code. However, even with Draper, repetitive patterns can emerge within decorators, compromising the DRY principle we hold so dear.

Enter Decorator Dryer, an outstanding companion gem for Draper that addresses these challenges head-on. This gem streamlines the decorator writing process, keeping them DRY and easy to manage, thereby enhancing the efficiency of our Rails applications.

The Problem In More Detail

Take dates as an example. Formatting dates is a very easy thing for a decorator to do. Just choose a date attribute, choose a format, and make a call to strftime. But what if your decorator needs to do this for 10 date attributes? You now have 10 almost identical methods in your decorator.
Even if you centralise your formatting logic into a reusable method, you still have to write 10 methods that call that method, each passing in a different attribute.

With Decorator Dryer, this is a thing of the past.

Why Choose Decorator Dryer?

Seamless Integration with Draper

Decorator Dryer seamlessly integrates with Draper, enhancing its capabilities by reducing redundancy in decorator classes. By using Decorator Dryer alongside Draper, you ensure a unified and efficient approach to managing your decorators.

Code Reduction and Improved Maintainability

One of the key benefits of Decorator Dryer is its ability to significantly reduce repetitive code within decorators. It extracts common decorator functionalities into reusable methods and leverages the power of meta-programming to eliminate the need for repetitive calls to those methods, leading to cleaner and more maintainable codebases.

Faster Development of Decorators

By eliminating redundant code and providing a structured way to organise shared functionalities, Decorator Dryer accelerates the development process. Developers can focus more on the unique aspects of their decorators, leading to faster iteration and deployment.

Getting Started with Decorator Dryer

Implementing Decorator Dryer into your Rails application is a straightforward process:

1. Installation:

Add Decorator Dryer to your application's Gemfile.

gem 'draper'
gem 'decorator_dryer'
And the execute:
bundle install

2. Inclusion:

Add Decorator Dryer to your top-level Draper decorator.

class ApplicationDecorator < Draper::Decorator
  include DecoratorDryer
end

3. Implementation:

class PersonDecorator < ApplicationDecorator
  to_date_format :date_of_birth, :date_of_graduation
  to_datetime_format :moment_of_birth
  to_time_format :lunch_time, :dinner_time
  to_precision_number :salary, :coffee_budget, precision: 2
  to_precision_number :height_in_meters, precision: 3
  to_attachment :profile_picture
end

4. Decorate your models:

date_of_birth = Date.new(2000, 1, 1)
date_of_graduation = Date.new(2018, 6, 6)
person = Person.create(date_of_birth: date_of_birth, date_of_graduation: date_of_graduation)
person.decorate.date_of_birth # ==> '2000-01-01'
person.decorate.date_of_graduation # ==> '2018-06-06'

Conclusion

Decorators are an essential part of Ruby On Rails applications, but they have a tendency to become overly repetitive, especially in larger application. For best results, keep the DRY.

Decorator Dryer stands as a valuable tool in the arsenal of any Ruby on Rails developer seeking cleaner, more maintainable code. By working seamlessly together with Draper, reducing code repetition, and expediting development, it's a gem that truly lives up to its name.

So, let's keep our decorators DRY and our codebases clean!

Check it out on Github: https://github.com/CodeTectonics/decorator_dryer.

Happy coding!