In many backend systems, we talk about business logic, application logic, and layered architecture — but what do these terms really mean in practice?
In this post, I’ll walk through how to distinguish between these types of logic, why it matters architecturally, and where they should live in a clean codebase. We’ll use real examples to ground the theory.
The Key Distinction: Application vs Business Logic
Let’s start by defining the two:
Application Logic
This is technical flow control — things like:
- Routing a request
- Validating input
- Filtering or paging data
- Transforming DTOs
- Invoking infrastructure services
It’s the orchestration that makes your system work, but it doesn’t express rules about how your business works.
Business Logic (aka Domain Logic)
This represents the core rules of your system — policies, constraints, and decisions that enforce correctness from a domain point of view.
Business logic answers questions like:
- “Can this user upload a document?”
- “Is this operation allowed based on the state of the case?”
- “Has the user paid for access?”
Even if there’s no commercial activity, these rules still form the behavioral foundation of your system.
Real Examples and How to Classify Them
Example 1: Upload Rules
“When a document is uploaded, uploading another one is not allowed unless the case is open.”
Type: Business Logic
This expresses a constraint based on entity state (“case is open”) and governs what users can do with documents.
Example 2: Turning On a Light
“Turn on the light if the user clicks the power button and the light is off.”
Type: Application Logic
This is a technical interaction rule — no domain constraints, just responding to user input and system state.
Example 3: Paid Access
“Turn on the light if the user clicks the button, the light is off, and the user has paid for the light.”
Type: Business Logic
The “user has paid” check enforces a policy — only certain users are allowed to perform an action. That makes it part of the domain.
What About Security Logic?
Security logic can span both application and business logic, depending on what it enforces:
- Application-level security: Technical protection like verifying tokens, redirecting unauthenticated users, or checking if a user is logged in.
- Business-level security: Domain-driven rules like “only managers can approve reports” or “a user may only edit their own profile.”
If a rule expresses who should be allowed to do something based on domain roles or context, it’s business logic.
Where Should Business Logic Live?
In Clean Architecture or Onion Architecture, you’d typically separate logic like this:
| Layer | Role | Example |
|---|---|---|
| Presentation | Controllers, endpoints | Receives request |
| Application | Coordinates flows | Calls use case, enforces flow |
| Domain | Encodes rules and policies | Checks like user.HasPaid() |
| Infrastructure | Talks to external systems | Repositories, DB, APIs |
Even if the application layer enforces a rule, the knowledge of the rule (what does “paid” mean?) should live in the domain layer.
Takeaways
- Business logic is not about money — it’s about rules that enforce the correctness of your system’s behavior.
- Application logic orchestrates things; business logic decides what is valid.
- Security logic can belong to either — but domain-driven access rules belong in the domain.
- Clean Architecture helps you separate these concerns — but don’t over-engineer if the system is simple.
Final Thought
Even in systems without traditional “business models”, the distinction between application logic and domain rules matters. It helps you build software that’s easier to test, maintain, and reason about.
If you start to notice that your AppService classes are full of if statements checking domain state — it might be time to start pushing that logic into the domain itself.