DEV Community

Saras Growth Space
Saras Growth Space

Posted on

LLD Domain Modeling: Business Rules & Invariants (The Rules Your System Must Never Break)

#lld #systemdesign #softwareengineering #codinginterview

In the previous posts, we learned about:

  • Entities
  • Value Objects

These help us model the business world.

But a question still remains:

Why do these objects exist?

The answer is simple:

To enforce business behavior correctly.

And business behavior is usually defined by:

Business Rules and Invariants.

Understanding them is one of the biggest shifts from writing code to designing systems.

What Is a Business Rule?

A Business Rule is:

A rule that defines how the business expects the system to behave.

Examples:

BookMyShow 

A seat cannot be sold twice.
Enter fullscreen mode Exit fullscreen mode

Uber 

A driver cannot complete a ride that never started.
Enter fullscreen mode Exit fullscreen mode

Amazon 

The final order amount must be correct.
Enter fullscreen mode Exit fullscreen mode

Banking 

An account cannot withdraw more than its available balance.
Enter fullscreen mode Exit fullscreen mode

These rules do not come from code.

They come from the business.

Software Does Not Invent Rules

Many beginners think:

Business Rules
↓
Code
Enter fullscreen mode Exit fullscreen mode

Reality is:

Business
↓
Business Rules
↓
Code
Enter fullscreen mode Exit fullscreen mode

The software's responsibility is not to create rules.

The software's responsibility is to enforce them.

What Is an Invariant?

An Invariant is:

A business rule that must always remain true.

Think of it as a rule the business cannot afford to violate.

Example

Suppose a movie seat is booked.

Invariant:

One seat
=
One booking
Enter fullscreen mode Exit fullscreen mode

Valid:

Seat A1
→ Booking #101
Enter fullscreen mode Exit fullscreen mode

Invalid:

Seat A1
→ Booking #101

Seat A1
→ Booking #102
Enter fullscreen mode Exit fullscreen mode

The invariant has been violated.

Business Rule vs Invariant

These terms are related but not identical.

Business Rule

Describes expected behavior.

Example:

Customers can cancel orders before shipment.
Enter fullscreen mode Exit fullscreen mode

Invariant

Must never become false.

Example:

A shipped order cannot become unshipped.
Enter fullscreen mode Exit fullscreen mode

Relationship:

Business Rules
        ↓
Some become critical enough to become
        ↓
Invariants
Enter fullscreen mode Exit fullscreen mode

Every invariant is a business rule.

Not every business rule is an invariant.

Why Invariants Matter More Than Features

Imagine a payment system with:

  • beautiful UI
  • excellent APIs
  • fast processing

But:

Money randomly disappears.
Enter fullscreen mode Exit fullscreen mode

Would anyone trust it?

No.

Because correctness matters more than features.

A system that is correct but simple is useful.

A system that is feature-rich but incorrect is dangerous.

Every Domain Has Invariants

Ride Sharing 

A driver cannot have two active rides simultaneously.
Enter fullscreen mode Exit fullscreen mode

Food Delivery 

An order cannot be delivered before it is accepted.
Enter fullscreen mode Exit fullscreen mode

Banking 

Balance cannot become negative beyond allowed limits.
Enter fullscreen mode Exit fullscreen mode

E-Commerce 

Order total must equal item total plus charges.
Enter fullscreen mode Exit fullscreen mode

BookMyShow 

A seat cannot be booked twice.
Enter fullscreen mode Exit fullscreen mode

Different systems.

Same concept.

Invariants Are Hidden Inside Requirements

Requirements rarely say:

Invariant:
...
Enter fullscreen mode Exit fullscreen mode

Instead they appear indirectly.

Requirement:

Users can book seats for a movie.
Enter fullscreen mode Exit fullscreen mode

A beginner sees:

Seat
Movie
Booking
Enter fullscreen mode Exit fullscreen mode

An experienced designer asks:

Can multiple users book the same seat?
Enter fullscreen mode Exit fullscreen mode

They're searching for invariants.

Strong Designers Look for "Never"

A useful trick:

Ask:

What should NEVER happen?

Examples:

A payment should never be processed twice.
Enter fullscreen mode Exit fullscreen mode 
A cancelled ride should never become active again.
Enter fullscreen mode Exit fullscreen mode 
A delivered order should never return to CREATED state.
Enter fullscreen mode Exit fullscreen mode

These statements often reveal invariants immediately.

Real Example: Order Lifecycle

Consider an order.

CREATED
    ↓
PAID
    ↓
SHIPPED
    ↓
DELIVERED
Enter fullscreen mode Exit fullscreen mode

One invariant might be:

DELIVERED
cannot occur before
SHIPPED
Enter fullscreen mode Exit fullscreen mode

Another might be:

PAID
cannot return to
CREATED
Enter fullscreen mode Exit fullscreen mode

Notice something important.

The important part is not the fields.

The important part is protecting valid business behavior.

Weak LLD Thinking 

What classes should I create?
Enter fullscreen mode Exit fullscreen mode

Strong LLD Thinking 

What business rules must never break?
Enter fullscreen mode Exit fullscreen mode

This question often leads to far better designs.

Why This Matters Later

As systems become larger, a new question appears:

Who is responsible for protecting these invariants?
Enter fullscreen mode Exit fullscreen mode

That question eventually leads us to:

Aggregates
Consistency Boundaries
Aggregate Roots
Enter fullscreen mode Exit fullscreen mode

We'll explore those in upcoming posts.

For now, focus on identifying invariants first.

The Most Important Insight

Entities describe:
Who exists

Value Objects describe:
What something means

Business Rules describe:
How the business operates

Invariants describe:
What must never be violated

The strongest domain models are built around protecting invariants.

One-Line Takeaway

An invariant is a business rule that must always remain true, and discovering these rules is one of the most important skills in Domain Modeling.

Top comments (0)