DEV Community

Saras Growth Space
Saras Growth Space

Posted on

LLD Domain Modeling: State Machines (Modeling Business Lifecycles)

#lld #systemdesign #softwareengineering #codinginterview

In the previous post, we learned that every domain has Business Rules and Invariants—rules that the system must never violate.

But many of these rules are not static.

They depend on where a business object is in its lifecycle.

For example:

  • An order can only be shipped after it is paid.
  • A ride can only be completed after it has started.
  • A booking cannot be cancelled after the event has ended.

These are not just business rules.

They are state-dependent business rules.

This is where State Machines become one of the most powerful tools in Domain Modeling.

What Is a State Machine?

A State Machine models:

The valid states of a business object and the valid transitions between those states.

Instead of asking:

"What fields does this object have?"

We ask:

"How does this object evolve over time?"

Every Entity Has a Story

Think about an Order.

It doesn't remain the same forever.

It progresses through different stages.

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

Each stage represents a business state.

The Order is still the same Entity.

Only its state changes.

State Is More Than a Field

Many beginners think:

Order {
    Status status;
}
Enter fullscreen mode Exit fullscreen mode

Problem solved?

Not really.

A status field only stores the current value.

It does not define:

  • Which states are valid.
  • Which transitions are allowed.
  • Which transitions are forbidden.

A State Machine defines the behavior around that state.

Why State Machines Matter

Suppose an Order is already delivered.

Can we move it back to "Created"?

DELIVERED
      ↓
CREATED
Enter fullscreen mode Exit fullscreen mode

Business says:

No.

This transition is invalid.

The State Machine prevents impossible business behavior.

Valid vs Invalid Transitions

Consider an Order.

Valid 

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

Invalid 

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

The business never allows these transitions.

Real-World Examples

Ride Sharing 

REQUESTED
      ↓
DRIVER_ASSIGNED
      ↓
IN_PROGRESS
      ↓
COMPLETED
Enter fullscreen mode Exit fullscreen mode

Food Delivery 

PLACED
      ↓
PREPARING
      ↓
OUT_FOR_DELIVERY
      ↓
DELIVERED
Enter fullscreen mode Exit fullscreen mode

BookMyShow 

AVAILABLE
      ↓
LOCKED
      ↓
BOOKED
Enter fullscreen mode Exit fullscreen mode

Banking Loan 

APPLIED
      ↓
UNDER_REVIEW
      ↓
APPROVED
      ↓
DISBURSED
Enter fullscreen mode Exit fullscreen mode

Every domain has objects that evolve through business states.

State Machines Protect Invariants

In the previous post we discussed invariants.

For example:

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

How do we enforce this?

By allowing only valid transitions.

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

Notice:

The State Machine becomes one mechanism for protecting business correctness.

State Machines Model Behavior, Not Screens

A common mistake is thinking:

State = UI screen.

Not necessarily.

The business state exists whether or not a user interface exists.

For example:

A payment gateway may move a Payment from:

PENDING
      ↓
SUCCESS
Enter fullscreen mode Exit fullscreen mode

without any user interaction.

The state belongs to the business process, not the UI.

Strong Domain Modeling Thinking

Instead of asking:

What fields does this object have?
Enter fullscreen mode Exit fullscreen mode

Ask:

How does this object evolve over time?
Enter fullscreen mode Exit fullscreen mode

This question often uncovers hidden business rules.

Common Beginner Mistakes

Treating state as just a string 

status = "Delivered";
Enter fullscreen mode Exit fullscreen mode

Without validating transitions.

Allowing any state to change into any other state

This creates impossible business scenarios.

Forgetting terminal states

For example:

DELIVERED
Enter fullscreen mode Exit fullscreen mode

or

CANCELLED
Enter fullscreen mode Exit fullscreen mode

may be terminal states where no further transitions are allowed.

Why This Matters in LLD Interviews

Interviewers often ask questions like:

  • Can an order be cancelled after shipment?
  • Can a ride restart after completion?
  • What happens if payment fails?

These are not API questions.

They are State Machine questions.

Candidates who model state transitions explicitly usually produce much cleaner designs.

Looking Ahead

We've now learned:

  • Entities
  • Value Objects
  • Business Rules
  • Invariants
  • State Machines

The next question becomes:

Who is responsible for ensuring all these rules remain consistent?

That leads us to one of the most misunderstood concepts in Domain Modeling:

Aggregates.

The Most Important Insight

A business object is not just data.

It has a lifecycle.

Modeling that lifecycle explicitly makes invalid business behavior difficult—or impossible—to represent.

One-Line Takeaway

A State Machine models how a business entity is allowed to evolve over time, ensuring that only valid state transitions are possible.

Top comments (0)