If you’ve ever shipped a bug caused by a business rule nobody could explain, this post is for you.
A pricing rule breaks in production.
Customers are affected.
Everyone is scrambling.
Then comes the worst question:
Who changed this… and why?
Sometimes the logic is buried in a service layer.
Sometimes it’s split across validators and feature flags.
Sometimes it lives in a Confluence doc nobody trusts anymore.
This isn’t a tooling problem.
It’s a structure problem.
Business Logic Has No First-Class Home
In most codebases, business logic is:
- Mixed with framework and infrastructure code
- Hard to review in isolation
- Poorly tested (or tested indirectly)
- Documented separately — if at all
When reviewing a PR, you often see how something was implemented, but not what rule actually changed.
That’s dangerous, because business logic is the real product.
Why This Matters More in the Age of AI
AI can generate controllers, services, and validators.
What it can’t generate is domain intent.
Business logic encodes:
- Pricing decisions
- Eligibility criteria
- Risk constraints
- Product strategy
As code generation becomes cheaper, clarity of intent becomes more valuable — not less.
The Idea: Separate Intent From Implementation
I wanted business rules to be:
- Explicit
- Versioned
- Tested
- Reviewable
- Framework-agnostic
That led to logicrepo.
What Is logicrepo?
logicrepo is a simple CLI that lets you:
- Define business rules in YAML
- Write tests for those rules
- Validate them in CI
No runtime magic.
No framework lock-in.
Just rules, clearly expressed.
Example (simplified)
rules:
discount:
when:
user.plan: "pro"
then:
apply_discount: 20
Tests focus on intent, not implementation details.
Why YAML?
Not because it’s trendy.
YAML is:
- Human-readable
- Easy to diff in PRs
- Reviewable by non-engineers
When a rule changes, PMs and domain experts can actually understand what changed — not just that something changed.
CI as a Guardrail
Running it is intentionally boring:
npx logicrepo check
Run it locally.
Run it in CI.
If a business rule breaks:
- The build fails
- The change is visible
- The intent is documented
No more silent logic drift.
This Is Not a Rules Engine
logicrepo does not execute your business logic at runtime.
Think of it as:
- A source of truth
- A contract
- A specification for business rules
Your application can consume it, or simply validate itself against it.
Try It Out
npx logicrepo check
GitHub:
https://github.com/alexdrimbe/logicrepo
I’d love to hear your thoughts:
- Where does your business logic live today?
- Have you been burned by logic drift before?
- Would something like this help your team?
Top comments (0)