Business Rules

The term we commonly use is business logic, though some refer to it as business rules. This logic is often scattered across software components. Some write it in the presentation layer, others place it in a dedicated business layer, and data people prefer having it within stored procedures.

But what exactly is business logic? And why is it crucial to distinguish between critical and non-critical rules when architecting a system? Understanding this distinction helps minimize the cost of change, maximize developer productivity, and ensure the long-term success of a project.

To illustrate the difference, we'll use a simple example: the interest rate on a bank loan. You'll see why isolating these rules matters. Get this right, and you'll build more maintainable software. Let’s begin.

What Are Business Rules?

Business rules define how a business makes or saves money. But not all business rules are equal. Some are critical business rules or domain-specific rules, like charging interest on a loan. These rules exist with or without software. They can be done manually on papers.

Other rules are non-critical or application-specific. They only exist because of automation, like requiring a validated credit score before loan approval. Understanding this difference is key to building clean software architecture.

Critical Business Rules: The Heart of Your Software

Critical business rules are core to the business itself. They don't rely on software. Think of the bank’s interest rate. It exists even without a computer.

Here's a simple example:

Entity: Loan

Data:
- Principal Amount: $10,000
- Interest Rate: 5% per year
- Period: 1 year

Rule (Interest Calculation):
Interest = Principal Amount × Interest Rate × Period  
Interest = $10,000 × 5% × 1 = $500

Critical rules naturally pair with critical business data. Together, they form isolated units called Domain Entities. Domain Entities hold this core logic, free of database or UI concerns.

Combining data and methods in the same place we call Domain Entities lies at the heart of Object Oriented development. By clearly isolating these rules, your domain remains stable, easy to test, and unaffected by continuous changes in application-specific requirements.

Application-Specific Business Rules: Use Cases

Unlike critical rules, application-specific rules exist only because we've built an automated system. They describe how users interact with the software.

Consider a bank’s loan approval process. The system first validates the applicant's data and credit score, then decides if loan estimation can proceed. This sequence is called a use case.

Here's a clear example:

Use Case: Apply for a New Loan

Input: Name, Address, Birthdate, SSN, etc.  
Output: Same information + credit score.

Steps:
1. Accept and validate name.
2. Validate address, birthdate, SSN, etc.
3. Retrieve credit score.
4. If credit score < 500, deny the loan.
5. Else, create customer and activate loan estimation.

Use cases define how and when critical business rules execute, coordinating interactions between users and your Domain Entities.

Why You Must Separate Critical and Application-Specific Rules

Domain Entities represent pure business logic. They are independent, knowing nothing about databases, user interfaces, or use cases. They reflect core business concepts, like the loan interest calculation, without any external influence.

Use cases, however, depend entirely on how the automated system operates. They control how and when entities interact, specifying the application’s workflow. They describe steps like gathering customer data and validating credit scores.

Domain Entities must never know about use cases. They are the high level policies that must remain isolated. Lower-level use cases depend on them. This clear separation keeps your core business logic stable, and reusable across different applications.

Conclusion

By distinguishing between critical business rules and non-critical rules, you create a software architecture that is stable and set for long term success.

Domain Entities encapsulate the critical rules, free from databases, UI, or use cases, making them stable, reusable and easy to test. Use cases define how users interact with the system, orchestrating workflows without altering critical business rules.

This clear separation keeps the system maintainable, reducing the cost of change while maximizing developer productivity.

Related Courses

Starting with a blank solution, watch me isolating domain business rules from application specific ones. This hands-on will show you how to design a software that is Soft. That is easy to change. → Designing a Rich Domain Order System & Pluggable Gateways