Business logic leaks across layers
Rules and decisions show up in controllers, mappers, jobs, UI, SQL, and integrations instead of one clear home.
- Where you see this
enterprise applicationsAPI plus frontend productsintegration-heavy systems
- Not necessarily a problem when
- light validation is intentionally duplicated near boundaries for safety and the canonical logic is still clear
- Often mistaken for
- every repeated check is bad duplication
- Time horizon
- medium-term
- Best placed to act
tech leadarchitect
The signal
What you would actually notice
Behavior becomes hard to trust, hard to test, and hard to change consistently.
Field observation
The same rule is partially duplicated in multiple runtime or architectural layers.
Also observed
- The UI validates it one way, the API another, and the batch job a third.
- We need to update this rule in three repositories.
Primary reading
What it usually indicates
Most likely underlying patterns when this signal shows up. Not a diagnosis, a starting hypothesis.
Usually indicates
Most likely underlying patterns when this signal shows up.
- missing domain layer
- convenience-driven implementation
- weak ownership of business rules
Stakes
Why it matters
Behavior becomes hard to trust, hard to test, and hard to change consistently.
Inspection
What to check next
Deliberate steps to confirm or disconfirm the primary reading above. Not a checklist. An order of inspection.
- rule ownership map
- tests by layer
- duplicate behavior across UI, API, and persistence
Diagnostic questions
Questions to ask the team, or yourself, before concluding anything.
- Where does this rule truly live?
- Which layer is canonical when behavior disagrees?
- Are we validating the same concept or redefining it in each layer?
Progression
Under the signal
Where this pattern tends to come from, what's holding it up, and where it goes if nothing changes.
Leading indicators
What tends to show up first.
- rule changes need coordinated edits across unrelated layers
- bugs appear as inconsistent behavior rather than hard failures
Common root causes
What is usually sitting under the signal.
- missing domain model
- deadline shortcuts
- layer-centric rather than behavior-centric design
Likely consequences
What happens if nothing changes.
- behavior drift
- hard-to-reproduce bugs
- expensive change coordination
Look-alikes
Not what it looks like
Patterns that can be mistaken for this signal, and 'fix' attempts that make it worse.
- every repeated check is bad duplication
Anti-patterns when responding
Responses that feel sensible and usually make the underlying pattern worse.
- fixing the visible instance of the rule without tracing all copies
- calling boundary validation a domain model
Context
Context and ownership
Where this signal surfaces, who sees it first, who can actually act, and how much runway there usually is before escalation.
Where it shows up
- enterprise applications
- API plus frontend products
- integration-heavy systems
Who sees it first
Before it escalates.
- senior engineers
- QA
- support during inconsistent bugs
Who can move on it
Not always the same as who notices it.
- tech lead
- architect
medium-term
How much runway there usually is before the signal hardens into the underlying pattern.
AI impact
AI effects on this signal
How AI-assisted and AI-driven workflows tend to amplify or hide this signal.
AI amplifies
Ways AI tooling tends to make this signal louder or more common.
- AI often continues the nearest local pattern, spreading copied business rules across layers faster.
AI masks
Ways AI tooling tends to hide this signal, so it keeps growing under the surface.
- Generated consistency in syntax hides inconsistency in actual source of truth.
Relationships
Connected signals
Related failure modes, decisions behind the signal, response playbooks, and neighboring red flags.