The Pragmat

Two rules. Four layers. Thirty years of building things that work.

· · ·

The Two Rules

All principles derive from two rules, applied in order. Everything else is commentary.

#1
Never compromise on working code.

Either the code works or it doesn't — end of story. Elegant architecture that doesn't ship is worthless. Ugly code that works beats perfect code that doesn't.

#2
Ruthlessly reduce cognitive load.

Once something works, the next priority is cognitive load — for the end user, for the support tech, for the developer, and for the product owner. If you can't hold it in your head, it's too complicated.

Rule One outranks Rule Two. Ship first. Clarify second. But never use Rule One as an excuse to ignore Rule Two permanently — working code that nobody can maintain is a ticking clock.

· · ·

Derived Principles

From the Two Rules, six principles emerge. None stand alone — each is an expression of working code and reduced cognitive load applied to a specific concern.

I
Simplicity Over Complexity

Complexity must earn the right to exist.

II
Minimize Usage Effort

Your user's cognitive capacity is not yours to consume.

III
Flexibility by Design

The best tools allow themselves to be productively 'abused'.

IV
Self-Documenting

Never document around ambiguity. Eliminate it.

V
Human Maintainable

Cleverness is debt. The interest compounds silently.

VI
Best Practices with Conviction

Always be ready to learn from the wisdom of others, but never compromise principles.

· · ·

DLPR — The Architecture

Most frameworks organize code by technical role — models, views, controllers. DLPR organizes code by the question it answers. Four questions, four layers, zero ambiguity about where code belongs.

DLPR was built from experience before I encountered Robert "Uncle Bob" Martin's work — and finding the alignment was validating. It strives to honor those shared principles while staying focused on what a solo developer can build and sustain.

D
Data — WHERE does data come from or go? The data layer holds things. It doesn't decide things.
L
Logic — WHAT do we do with the data? This is where decisions are made. The buck stops here.
P
Presentation — HOW do we deliver results? Formatting only. No judgment calls.
R
Routing — WHY is this code running? A request arrived. Routing is purpose meeting execution.

Documentation

The DLPR Alpha 1 documentation is available at github.com/jeremiahstover/dlpr — architecture, middleware, guides, and standards extracted from a production codebase.

The Decision Test

If you can't immediately identify which layer a piece of code belongs in, the code is doing too much. DLPR doesn't just organize — it exposes complexity that shouldn't exist. Every violation of layer boundaries is a signal that something needs to be decomposed.

The Flow

Every request enters through Routing. Routing calls Logic. Logic calls Data. The result travels back up to Routing, which then calls Presentation as needed — or delivers the response directly. There are no entry points to any other layer. Routing is the front door. Everything else is behind it.

Settled Decisions

Some things have been decided through experience. They don't need to be revisited — they need to be executed.

Architecture is always DLPR. ORMs are never used — they obfuscate the data layer and add ambiguity where clarity is the entire point.

· · ·
"The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise." — Edsger Dijkstra

The Pragmat is the professional identity of Jeremiah Stover — thirty years of building systems for businesses large and small, distilled into a philosophy that values working code over theoretical elegance, understandable over clever, and pragmatic over pure.