Business Logic

Building a service generates a pile of decisions that have nothing to do with technology. How many documents a team on the free plan can create. How many days of grace a failed payment gets. Whether someone invited to a document can delete it. Programming knowledge doesn't answer any of those questions — the company decides, and once it has, the decision has to live somewhere in the code.

Trouble starts when "somewhere" isn't defined. Whoever built the web screens drops a condition into the screen code: block the button past three documents. Months later someone builds the mobile app without knowing that rule exists, and the app happily creates five. Support gets a ticket saying it works fine in the app, and only then does it surface that the rule was never in one place — there was a copy per screen.

The phrase business logic comes out of the agreement to gather those rules into one spot. Not the code that draws screens, not the code that stores data, but a separate place that decides, with every path routed through it. Then a rule change has exactly one place to be made.

The path a request takes splits into four layers.

1. Screen — what the user sees and clicks, the frontend. Pressing the button sends a request to the server.
2. Passage — the layer that receives the request, checks who sent it, and records that it happened. Middleware does this work, and it only looks at things common to every feature, like whether the caller is logged in or how often they're calling.
3. Rules — where business logic sits. It decides whether to allow this request and, if so, what changes.
4. Storage — the decision gets written to the database, the system that stores data and hands it back. It inserts and deletes what it's told to and decides nothing.

What actually happens in layer 3 is a run of condition checks. For a request to create a new document: check the team's plan, and if it's the free plan, count the existing documents and refuse past three. If the team's payment failed, check how many days ago. Within seven days, reads are allowed; from day eight the workspace locks. Nothing there is technical — every branch is a decision somebody at the company made and wrote down.

The reason rules belong here is that this layer is the one path everything shares. Created from the web, from the app, or by an outside developer calling the API — the API being the agreed interface programs use to talk to each other — the request ends up here. Put the rule in the screen layer instead and you get one copy per screen, and the copies only have to disagree once for a customer to notice. None of this means dropping the checks in the screen: those exist to tell users early, so nobody fills in a form for a document they aren't allowed to create. They just aren't the final word.

The term travels through three situations.

1. Between product and engineering — a policy written in the PRD, the product requirements document stating what gets built, why, and what counts as done, becomes the code in this layer almost line for line. If the document says "seven days of grace" and never says whether day seven runs from the moment the card was declined or from midnight that day, someone fills that blank in arbitrarily while writing the code.
2. Work that runs without a person — rules are needed outside button presses too. The cron job that generates invoices on the first of the month has to decide which team is billed how much, and the same goes for bulk processing run as a background job. So the rules go somewhere both paths can call, not inside the code the screen calls.
3. When the structure gets reworked — scattered rules mean something gets missed on every change. Domain-driven design (DDD) tackles this directly as a design approach: carry the words and boundaries used in the business into the structure of the code. When what a product manager calls a workspace is named the same thing in the code, a conversation is enough to settle which file to open when a rule changes.

"It's not a UI problem. The business logic differs between the app and the web."

Two copies of the same rule exist and they've drifted apart.

"Don't make that call in the frontend — move it into the logic layer."

A request to relocate the final decision to the rules layer on the server.

"The doc just says seven days. Seven days from when?"

Turning a rule into code requires a boundary the document never set.

This conversation ran long at Pagedeck once. Mia wrote the policy setting the failed-payment grace period at seven days, and before starting the implementation Theo came back with three questions. Does day one start when the card processor responds, or at midnight that day? During the grace period, does downloading an existing document count as reading? If payment succeeds mid-grace, how many days get billed? All three need answers before anything can be written, and none of them were in the document.

What changed the outcome was that Mia didn't decide on the spot but asked Sofia. Enterprise customers keep card details with a finance administrator, so it takes them days just to notice the failure — and the grace period became fourteen days instead of seven.

Many people picture business logic as something like a complicated algorithm, because "logic" sounds hard. In practice the code in this layer is mostly a handful of conditionals. Check whether the plan is free, count, refuse past the limit. What's hard isn't the code but deciding what the conditions should be. Reading this layer shows every decision the company has made so far, and it's also where you find decisions that exist only in code because they were never written into a product document.

The second mistake is treating a screen-side check as the business logic and going light on the server. The screen already blocked it, so checking twice feels wasteful. But the screen is territory the user controls, and there are many ways around it. Re-enable the button from developer tools, or send the request straight to the server with no browser involved, and the screen's check means nothing. Leave the server-side check out and somebody really does create a hundred documents on the free plan, at which point the data is already in and undoing it costs more.