DEV Community: Saras Growth Space

LLD UML & Visualization: State Diagrams — Modeling How Objects Evolve Over Time

Saras Growth Space — Tue, 21 Jul 2026 17:00:00 +0000

"Most software bugs don't happen because developers create the wrong classes. They happen because the system allows an object to enter a state it should never have been allowed to reach."

Imagine you're building an e-commerce application.

A customer places an order.

The payment succeeds.

The warehouse ships the package.

Everything looks fine.

Now imagine the system accidentally allows the order to be cancelled after it has already been delivered.

Or suppose a refund is issued even though the payment failed.

Neither problem is caused by poor coding syntax.

They're caused by invalid state transitions.

Every important object in a software system goes through a lifecycle.

Understanding that lifecycle is one of the most valuable skills in Low-Level Design.

That's exactly what State Diagrams help us model.

Why Do State Diagrams Exist?

In the previous articles, we explored different perspectives of a software system.

Class Diagrams helped us understand the structure.
Sequence Diagrams showed how objects collaborate.
Use Case Diagrams captured what users want to accomplish.

But there's still one question left unanswered.

How does an object change throughout its lifetime?

Some objects are simple.

A Country rarely changes.

Others are constantly evolving.

Think about:

an Order
a Payment
a Ride
a Booking
a Support Ticket

Their behavior depends entirely on their current state.

A customer can cancel an order before it is shipped.

Not after it has been delivered.

The system needs a way to model these business rules.

That's the purpose of a State Diagram.

What Is a State Diagram?

A State Diagram models the lifecycle of a single object.

Instead of showing interactions between multiple objects, it focuses on one question:

What states can this object be in, and how does it move between them?

Think of it as a roadmap for an object's life.

Every important business object follows one.

Understanding States

A state represents a condition that an object is currently in.

Consider an online order.

Created

Confirmed

Paid

Shipped

Delivered

Cancelled

At any given moment, the order exists in exactly one of these states.

Its current state determines what actions are allowed.

Transitions

Objects don't remain in the same state forever.

They move from one state to another.

These movements are called transitions.

Created
    │
    ▼
Confirmed
    │
    ▼
Paid
    │
    ▼
Shipped
    │
    ▼
Delivered

A transition represents change.

Something happens.

The object's status evolves.

Events Trigger Transitions

Objects don't change state randomly.

Something causes the transition.

These triggers are called events.

For example:

Created
    │
(payment succeeds)
    ▼
Paid

Ride Requested
      │
(driver accepts)
      ▼
Driver Assigned

Events are the bridge between user actions and business behavior.

A Real-World Example: Online Shopping

Let's look at the complete lifecycle of an order.

Created
    │
    ▼
Confirmed
    │
    ▼
Paid
    │
    ▼
Packed
    │
    ▼
Shipped
    │
    ▼
Delivered

Now let's think about cancellations.

Should a customer be able to cancel at every stage?

Probably not.

Maybe cancellation is allowed only before shipping.

That business rule naturally becomes part of the state model.

Created
    │
    ├────────► Cancelled
    │
Confirmed
    │
    ├────────► Cancelled
    │
Paid
    │
    ├────────► Cancelled
    │
Packed
    │
Shipped
    │
Delivered

Notice something important.

The diagram isn't just showing states.

It's expressing business policy.

Another Example: Ride Sharing

Now consider a ride-sharing platform.

A ride may move through these states.

Requested
    │
    ▼
Driver Assigned
    │
    ▼
Driver Arriving
    │
    ▼
Ride Started
    │
    ▼
Ride Completed

Cancellation might be allowed here.

Requested
    │
    ├────────► Cancelled
    │
Driver Assigned
    │
    ├────────► Cancelled

But once the ride has started, cancellation rules become completely different.

The current state determines the allowed actions.

Payment Is Also a Lifecycle

Many beginners think payment has only two outcomes.

Success or failure.

Real systems are far more nuanced.

Initiated
    │
    ▼
Pending
   ├────────► Failed
   │
   └────────► Successful
                 │
                 ▼
             Refunded

Now think about the business rules.

Can a failed payment be refunded?

No.

Can a successful payment fail afterward?

No.

The state machine prevents these impossible scenarios.

Why Business Rules Belong Here

State Diagrams are often where business rules become visible.

For example:

Order Delivered
      │
      ▼
Cancel Order

Should this transition exist?

Probably not.

Instead:

Delivered

(No cancellation allowed)

Similarly:

Payment Failed
      │
      ▼
Issue Refund

Again, that transition doesn't make sense.

By thinking in terms of states, invalid business behavior becomes much easier to detect.

State Diagrams Are Not Flowcharts

This is one of the most common misunderstandings.

A flowchart asks:

What steps does the process follow?

A State Diagram asks:

What condition is this object currently in?

These are very different questions.

A checkout process might involve dozens of steps.

The order itself may only transition through six or seven meaningful states.

Don't confuse process flow with object lifecycle.

Weak Thinking vs Strong Thinking

Weak Thinking

An order is just an object.

Strong Thinking

An order has a lifecycle,
and every action depends
on its current state.

Weak Thinking

Let's validate everything
inside the controller.

Strong Thinking

The object's current state
should determine what is allowed.

Weak Thinking

Every action is always available.

Strong Thinking

Available actions change
as the object evolves.

Common Beginner Mistakes

Mixing multiple objects

A State Diagram should describe one object's lifecycle.

Don't combine Orders, Payments, Deliveries, and Notifications into the same diagram.

Keep the focus clear.

Ignoring failure states

Many diagrams only show the happy path.

Real systems also have:

failures
cancellations
retries
expirations
refunds

Ignoring these states often leads to incomplete designs.

Allowing impossible transitions

Ask yourself:

"Would this make sense in the real world?"

If not, it shouldn't appear in your State Diagram.

Thinking only about implementation

State Diagrams are primarily about business behavior.

Implementation comes later.

The business lifecycle should drive the code—not the other way around.

Interview Perspective

In Low-Level Design interviews, candidates often focus heavily on classes and APIs.

Strong candidates go one step further.

They ask questions like:

What states can this object have?
What transitions are allowed?
What business rules prevent invalid transitions?
What happens when something fails?

These questions demonstrate a deep understanding of real-world systems.

Interviewers appreciate candidates who naturally think in terms of object lifecycles because it shows they understand software beyond syntax.

The Most Important Insight

Every important business object has a lifecycle.

Understanding that lifecycle is often more valuable than understanding the code itself.

A well-designed system doesn't just know what objects exist.

It knows what those objects are allowed to become.

When you model state correctly, many business bugs disappear before a single line of code is written.

One-Line Takeaway

Great software doesn't just model objects—it models how those objects are allowed to evolve over time.

LLD UML & Visualization: Use Case Diagrams — Understanding What the System Should Do Before Designing It

Saras Growth Space — Tue, 21 Jul 2026 16:30:00 +0000

"One of the fastest ways to design the wrong system is to start thinking about classes before understanding what the system is actually supposed to do."

Imagine someone asks you to design an online food delivery platform.

Many developers immediately begin thinking about classes.

Customer
Restaurant
Order
Payment
DeliveryPartner

But here's the problem.

At this stage, you don't even know what the system is expected to do.

Can customers schedule orders?

Can restaurants reject orders?

Can delivery partners cancel deliveries?

Does the system support cash on delivery?

Before discussing implementation, we first need to understand the goals of the people using the system.

That's exactly what Use Case Diagrams help us do.

They shift our focus from how the software is built to what the software is expected to accomplish.

Why Do Use Case Diagrams Exist?

Every software project begins with requirements.

Before we discuss classes, APIs, databases, or services, someone has to answer a much simpler question.

"What should this system actually do?"

Surprisingly, many design mistakes happen because engineers jump directly into implementation without fully understanding the problem.

Use Case Diagrams solve this by helping everyone answer three simple questions:

Who uses the system?
What are they trying to accomplish?
What responsibilities belong to the system?

Instead of thinking like programmers, they encourage us to think like product designers and users.

What Is a Use Case Diagram?

A Use Case Diagram is a high-level view of a system that focuses on user goals.

It doesn't explain algorithms.

It doesn't describe databases.

It doesn't model object relationships.

Instead, it captures the different ways users interact with the system.

Think of it as answering this question:

"If I were using this application, what would I expect it to help me do?"

The Three Building Blocks

Every Use Case Diagram is built from just three core ideas.

Actors

Actors are the entities that interact with the system.

They are usually:

users
administrators
external systems
third-party services

An actor is not necessarily a person.

It simply represents a role.

For example, the same individual could act as both:

Customer
Seller

depending on what they are doing.

Use Cases

A use case represents a goal.

Examples include:

Search Product
Place Order
Cancel Booking
Process Payment
Track Delivery

Notice that use cases are always expressed as actions.

They describe what the user wants to achieve.

System Boundary

One of the most overlooked concepts in UML is the system boundary.

It defines where your system begins and ends.

Everything inside the boundary is your responsibility.

Everything outside belongs to another system.

Consider a food delivery platform.

                Payment Gateway
                       │
Customer ─────┐        │
              ▼        ▼
     -------------------------
    |   Food Delivery App     |
    |-------------------------|
    | Search Restaurant       |
    | Place Order             |
    | Track Delivery          |
    | Cancel Order            |
     -------------------------
              ▲
              │
         Restaurant

This simple box answers an important question:

What exactly are we building?

Without a clear system boundary, software projects often grow beyond their intended scope.

Thinking in User Goals

One of the biggest mindset shifts in software design is learning to think in terms of goals instead of features.

Consider Amazon.

Instead of thinking:

Product
Cart
Inventory
Order

Ask yourself:

What is the customer actually trying to accomplish?

The answers look very different.

Search Products

Add Item to Cart

Checkout

Track Order

Cancel Order

These are use cases.

Notice that they're all meaningful business goals.

A Real-World Example: Ride Sharing

Let's identify the actors first.

Customer

Driver

Admin

Payment Gateway

Now let's think about their goals.

Customer:

Request Ride
Cancel Ride
Track Driver
Pay Fare

Driver:

Accept Ride
Start Trip
Complete Trip

Admin:

Suspend Driver
Resolve Complaints

Payment Gateway:

Process Payment

Immediately, we gain a much clearer understanding of what the platform actually needs to support.

Notice that we still haven't discussed implementation.

That's intentional.

One System, Many Perspectives

Different stakeholders care about different things.

A Product Manager asks:

"Can the customer cancel an order?"

A Customer Support representative asks:

"Can we refund cancelled bookings?"

A Designer asks:

"How does the booking flow work?"

A Backend Engineer asks:

"Which services should handle payment?"

Only one of these questions is about implementation.

The others are about understanding the business.

Use Case Diagrams help align everyone before technical design begins.

Include vs Extend

Not every user action is independent.

Some actions always happen together.

Others happen only under specific conditions.

This is where Include and Extend become useful.

Include

An included use case is mandatory.

Whenever the main use case executes, the included one also executes.

Example:

Place Order
      │
      ▼
Process Payment

Every successful order must process payment.

Payment is therefore included.

Extend

An extended use case is optional.

It occurs only under certain conditions.

Example:

Cancel Order
      │
      ▼
Refund Payment

A refund is not required for every cancellation.

It depends on business rules.

That's why it extends the cancellation flow instead of being mandatory.

Weak Thinking vs Strong Thinking

Weak Thinking

What classes should I create?

Strong Thinking

What goals are users trying to achieve?

Weak Thinking

Let's design the database first.

Strong Thinking

Let's first understand
what problem we're solving.

Weak Thinking

Every requirement is technical.

Strong Thinking

Every technical solution
starts with a business need.

Common Beginner Mistakes

Treating Use Cases as Classes

This is one of the most common mistakes.

Writing:

Customer

Order

Payment

is not a Use Case Diagram.

These are domain objects.

Use cases should represent actions.

Place Order

Make Payment

Track Delivery

Ignoring External Systems

Real systems rarely work in isolation.

Payment gateways.

SMS providers.

Email services.

Maps.

Identity providers.

These all interact with your application.

Good Use Case Diagrams acknowledge those interactions.

Making Use Cases Too Technical

A use case should never be:

Call Payment API

That's an implementation detail.

Instead:

Make Payment

The system can decide later how that payment is processed.

Forgetting the System Boundary

Without defining the system boundary, teams often argue about features that don't even belong in the current project.

A clear boundary keeps everyone focused.

Interview Perspective

One of the biggest differences between experienced candidates and beginners appears before any code is written.

Experienced candidates spend a few minutes understanding the problem.

They identify:

the actors
the business goals
the scope
external systems

Only then do they move toward Class Diagrams and implementation.

Interviewers appreciate this approach because it demonstrates disciplined engineering thinking rather than rushed coding.

The Most Important Insight

Use Case Diagrams are not about software.

They're about people.

Before designing databases, APIs, or classes, experienced engineers first understand what users are trying to accomplish.

When user goals are clear, technical decisions become significantly easier.

When user goals are misunderstood, even beautifully written code solves the wrong problem.

One-Line Takeaway

Good software begins with understanding user goals—not with writing classes.

LLD UML & Visualization: Sequence Diagrams — Understanding How Objects Collaborate

Saras Growth Space — Tue, 21 Jul 2026 16:00:00 +0000

"A well-designed system isn't just about having the right classes. It's about how those classes collaborate to accomplish real work."

In the previous article, we learned how Class Diagrams help us model the structure of a system.

They answer questions like:

What objects exist?
What responsibilities do they own?
How are they related?

But they leave one important question unanswered.

What actually happens when a user clicks a button?

Knowing that a Customer, Order, and Payment class exist doesn't explain how an order gets placed.

Who creates the order?

Who validates the payment?

Who updates the inventory?

Who sends the confirmation?

This is where Sequence Diagrams become incredibly valuable.

Instead of showing what exists, they show how objects collaborate over time.

Why Class Diagrams Aren't Enough

Imagine someone hands you this Class Diagram.

Customer
Cart
Order
Payment
Inventory
Notification

You understand the building blocks.

But if someone asks:

"Walk me through what happens when a customer places an order."

You still don't know the answer.

The missing piece is behavior.

Class Diagrams describe structure.

Sequence Diagrams describe interaction.

What Is a Sequence Diagram?

A Sequence Diagram visualizes how different objects communicate while performing a specific task.

Instead of asking:

"What objects exist?"

It asks:

"Who talks to whom, and in what order?"

Every interaction is represented as a message passed from one object to another.

Together, these messages tell the complete story of how a feature works.

Think of it as watching a movie instead of looking at a photograph.

Time Flows Downward

One of the most important concepts in Sequence Diagrams is that time always moves from top to bottom.

Every message appears below the previous one.

Start
 │
 ▼
Validate Request
 │
 ▼
Create Order
 │
 ▼
Process Payment
 │
 ▼
Update Inventory
 │
 ▼
Send Confirmation

Reading a Sequence Diagram is almost like reading a story.

Each action naturally follows the previous one.

The Main Participants

Every Sequence Diagram is made up of participants.

These participants are usually:

users
controllers
services
repositories
databases
external systems

For example:

Customer

OrderController

OrderService

InventoryService

PaymentService

Database

Each participant represents something that takes part in completing the request.

Lifelines

Every participant has a vertical line beneath it.

This is called a lifeline.

Customer        OrderService        Database
    │                  │                 │
    │                  │                 │
    │                  │                 │

A lifeline simply shows that the participant exists during the interaction.

Messages travel between these lifelines.

Messages Represent Method Calls

Whenever one object asks another object to perform work, we draw a message.

Customer
    │
    │ placeOrder()
    ▼
OrderController

That message might represent:

a method call
an API request
an event
a service invocation

The exact implementation isn't important.

The collaboration is.

A Simple Login Flow

Let's model a login request.

User
 │
 ▼
AuthController
 │
 ▼
AuthService
 │
 ▼
UserRepository
 │
 ▼
Database

Now let's walk through it.

The user submits login credentials.

The controller receives the request.

The controller delegates authentication to the service.

The service retrieves the user from the repository.

The repository queries the database.

The result travels back through the same chain.

Even without reading code, the runtime behavior is immediately clear.

Why Controllers Delegate

One pattern appears in almost every backend system.

User
 │
 ▼
Controller
 │
 ▼
Service
 │
 ▼
Repository
 │
 ▼
Database

Beginners sometimes wonder why there are so many layers.

Because each layer has a different responsibility.

The controller receives requests.

The service contains business logic.

The repository handles persistence.

Each component focuses on one job.

Sequence Diagrams make this separation obvious.

A Real-World Example: Ordering Food

Imagine a customer places an order using a food delivery app.

The interaction might look like this.

Customer
    │
    ▼
Order Controller
    │
    ▼
Order Service
    │
    ├────────► Inventory Service
    │
    ├────────► Payment Service
    │
    └────────► Notification Service

Notice something interesting.

The OrderService doesn't do everything itself.

Instead, it coordinates multiple specialized services.

This is exactly how large backend systems are designed.

Synchronous vs Asynchronous Communication

Not every interaction behaves the same way.

Some operations require an immediate response.

Others don't.

Synchronous Communication

The caller waits until the work finishes.

Checkout
     │
     ▼
Payment Service
     │
(wait)
     │
Success

The user cannot continue until payment completes.

Asynchronous Communication

The caller continues immediately.

Order Created
      │
      ├────────► Email Service
      └────────► Analytics Service

The order is successfully created even if the email is sent a few seconds later.

This improves responsiveness and scalability.

Understanding when to use each approach is an important engineering skill.

A Sequence Diagram Tells a Story

Consider booking a movie ticket.

User
 │
 ▼
Booking Controller
 │
 ▼
Booking Service
 │
 ▼
Seat Service
 │
 ▼
Payment Service
 │
 ▼
Booking Repository

Read it like a story.

The user requests a booking.

The booking service checks seat availability.

If seats are available, payment is processed.

Only after payment succeeds is the booking stored.

The order matters.

Changing the order changes the business behavior.

Weak Thinking vs Strong Thinking

Weak Thinking

I'll call whichever service
I need whenever I want.

Strong Thinking

Every interaction should have
a clear responsibility and sequence.

Weak Thinking

The controller should handle
all the business logic.

Strong Thinking

Controllers coordinate requests.

Services implement business logic.

Weak Thinking

The database is the system.

Strong Thinking

The database is just one participant
in a larger collaboration.

Common Beginner Mistakes

Skipping intermediate layers

Many beginners draw something like this.

User
 │
 ▼
Database

Real applications rarely work this way.

Business logic almost always sits between the user and the database.

Mixing responsibilities

Controllers should not calculate discounts.

Repositories should not validate payments.

Each participant should perform exactly one type of work.

Ignoring alternative flows

Happy paths are easy.

Real systems also handle:

payment failures
inventory shortages
invalid requests
retry mechanisms

Good Sequence Diagrams acknowledge these possibilities.

Trying to show everything

A Sequence Diagram should explain one specific scenario.

Trying to model every possible path quickly makes the diagram unreadable.

Keep each diagram focused.

Interview Perspective

In Low-Level Design interviews, interviewers often ask:

"Walk me through what happens when the user places an order."

They're not asking for code.

They're evaluating your ability to think about runtime behavior.

Strong candidates naturally explain:

who receives the request
where business logic lives
which services collaborate
how data flows
when the request completes

Even if you never draw a formal Sequence Diagram, thinking this way makes your explanations significantly stronger.

The Most Important Insight

Class Diagrams tell you what exists.

Sequence Diagrams tell you how those objects collaborate.

A system isn't successful because it has good classes.

It's successful because those classes communicate in a clear, predictable, and maintainable way.

Understanding interactions is just as important as understanding structure.

One-Line Takeaway

Great software isn't just a collection of well-designed objects—it's a collection of well-designed conversations between those objects.

LLD UML & Visualization: Class Diagrams — Modeling the Structure of Your System

Saras Growth Space — Tue, 21 Jul 2026 15:30:00 +0000

"Every software system is made of objects. The challenge isn't creating those objects—it's deciding what they are responsible for and how they should relate to one another."

If you've ever started an LLD problem by immediately creating classes like User, Order, and Payment, you're not alone. Most beginners do exactly that.

The problem is that creating classes is easy.

Creating the right classes with the right relationships is hard.

That's where Class Diagrams become invaluable.

They're not just boxes connected by lines. They're a way of thinking about the structure of a software system before writing code.

In this article, we'll learn how experienced engineers use Class Diagrams to model software, identify relationships, and create maintainable designs.

What Is a Class Diagram?

A Class Diagram is a visual representation of the static structure of a system.

Instead of showing how the system behaves, it shows:

what objects exist
what information they hold
what responsibilities they own
how they are related

Think of it as the architectural blueprint of your software.

Before constructing a building, architects don't begin by laying bricks.

They first design the structure.

Similarly, before implementing classes, experienced engineers first think about how those classes fit together.

Why Do Class Diagrams Exist?

Imagine someone asks you to design Amazon's shopping cart.

Most beginners immediately start writing something like:

class User {}

class Cart {}

class Product {}

class Order {}

Nothing is technically wrong with these classes.

But they don't answer the important questions.

Can one user have multiple carts?
Does an order own its items?
Can a product exist without inventory?
Who is responsible for calculating the total amount?

A Class Diagram forces you to answer these questions before implementation.

It shifts your focus from syntax to design.

Thinking Like an Engineer

Experienced engineers don't begin with classes.

They begin with responsibilities.

Instead of asking:

"What classes should I create?"

They ask:

"What responsibilities exist in this business domain?"

Only after understanding responsibilities do they identify the classes that should own them.

This mindset leads to cleaner, more maintainable designs.

The Anatomy of a Class

Every class usually consists of three parts.

+------------------------+
| Customer               |
+------------------------+
| id                     |
| name                   |
| email                  |
+------------------------+
| login()                |
| updateProfile()        |
+------------------------+

The top section represents the class itself.

The middle section contains the data the object owns.

The bottom section contains the behavior the object performs.

Even without reading code, you can quickly understand the purpose of this object.

Attributes and Behavior

One common beginner mistake is treating classes as containers for data.

In object-oriented design, a class should own both:

state (attributes)
behavior (methods)

Consider a shopping cart.

Instead of thinking:

Cart

items
total

Think:

Cart

items
addItem()
removeItem()
calculateTotal()
clear()

A well-designed object doesn't just store information.

It knows how to manage its own state.

Visibility Matters

Not everything inside a class should be accessible from outside.

Class diagrams use visibility to communicate intent.

+ Public
- Private
# Protected

For example:

+----------------------+
| Customer             |
+----------------------+
| - id                 |
| - email              |
+----------------------+
| + login()            |
| + logout()           |
+----------------------+

The attributes are private because they shouldn't be modified directly.

The behavior is public because that's how other parts of the system interact with the object.

Visibility isn't just syntax.

It's a way of protecting the integrity of your objects.

Relationships Are More Important Than Classes

Here's a surprising truth.

Interviewers usually care less about the number of classes you create and more about how those classes relate to each other.

The relationships define the architecture.

Without relationships, a Class Diagram is simply a list of disconnected objects.

Association

Association represents a simple connection between two classes.

For example:

Customer -------- Order

This simply means:

A customer can place orders.

Neither object owns the other.

They simply know about each other.

Multiplicity

Relationships become much more meaningful when we describe how many objects are involved.

Customer 1 -------- * Order

This tells us:

one customer can have many orders
every order belongs to one customer

Without multiplicity, the relationship is incomplete.

Experienced engineers rarely ignore it.

Aggregation

Aggregation represents a has-a relationship with weak ownership.

Consider a football team.

Team ◇──── Player

A team has players.

But players continue to exist even if the team is dissolved.

The lifetime of the player doesn't depend on the team.

Aggregation models this independence.

Composition

Composition also represents a has-a relationship.

But this time, ownership is much stronger.

House ◆──── Room

A room doesn't meaningfully exist without a house.

If the house disappears, its rooms disappear as well.

Composition represents this lifecycle dependency.

This distinction is incredibly important in real-world software.

For example:

Order ◆──── OrderItem

An OrderItem has no meaning outside its order.

It should not exist independently.

Inheritance

Inheritance models an is-a relationship.

Vehicle
   ▲
   │
 Car

A car is a vehicle.

A bike is a vehicle.

Inheritance allows child classes to reuse behavior from a more general parent.

However, experienced engineers are cautious with inheritance.

If the relationship isn't truly "is-a", inheritance often creates more problems than it solves.

A Practical Example

Let's model a simplified online shopping system.

Customer
    │
    ├──── Cart
    │         │
    │         └──── Products
    │
    └──── Orders
              │
              └──── Order Items

Even this simple structure communicates a lot.

You can immediately understand:

customers own carts
customers place orders
orders contain order items
carts reference products

No implementation required.

Weak Thinking vs Strong Thinking

Weak Thinking

User should know everything.

Strong Thinking

Each object should own only
its own responsibilities.

Weak Thinking

Everything should inherit
from one big base class.

Strong Thinking

Inheritance should model
true "is-a" relationships.

Weak Thinking

I'll decide relationships later.

Strong Thinking

Relationships are part of the design,
not an afterthought.

Common Beginner Mistakes

Creating classes before understanding the domain

Many developers immediately start coding.

Instead, spend time understanding the business.

The classes often reveal themselves naturally.

Confusing composition and aggregation

Ask yourself one question.

Can the child exist independently?

If yes, aggregation is probably appropriate.

If no, composition is usually the better choice.

Making every field public

Objects should protect their own state.

Encapsulation isn't about hiding data.

It's about ensuring objects remain valid.

Creating "God Objects"

Sometimes beginners create one enormous class that manages everything.

OrderManager

Creates Orders
Processes Payments
Calculates Discounts
Updates Inventory
Sends Notifications

This violates the Single Responsibility Principle and quickly becomes difficult to maintain.

Interview Perspective

In Low-Level Design interviews, Class Diagrams are rarely evaluated based on notation alone.

Interviewers usually look for answers to questions like:

Did you identify the right entities?
Are responsibilities well separated?
Are relationships accurate?
Is ownership modeled correctly?
Does the design feel maintainable?

Two candidates may draw different diagrams.

Both can be correct if their reasoning is sound.

That's why you should always explain why you chose a particular relationship.

Your thought process matters as much as the diagram itself.

The Most Important Insight

A Class Diagram isn't a picture of your code.

It's a picture of your design.

Good engineers don't create classes because the business has nouns.

They create classes because responsibilities need clear owners, and relationships need clear boundaries.

When your structure is correct, implementation becomes dramatically easier.

One-Line Takeaway

Strong software isn't built from well-written classes—it is built from well-designed relationships between those classes.

LLD UML & Visualization: Why Software Engineers Draw Before They Code

Saras Growth Space — Tue, 21 Jul 2026 15:00:00 +0000

"The biggest difference between a beginner and an experienced engineer isn't the code they write—it's the clarity they have before they write it."

We've spent the last few articles building the foundation of Low-Level Design (LLD). We explored requirements, SOLID principles, abstraction, decomposition, coupling, cohesion, and design thinking. Those concepts taught us how to think about software design.

But there's still one important question left unanswered.

How do experienced engineers communicate those ideas?

Imagine you're designing Amazon's shopping cart with your team. You have the architecture in your head, someone else is thinking about payments, another engineer is responsible for inventory, and your tech lead wants to discuss edge cases.

Writing code isn't the first step.

Instead, someone walks to a whiteboard and starts drawing.

A few boxes.

Some arrows.

A couple of labels.

Within minutes, everyone in the room understands the design.

That's exactly why UML exists.

In this article, we'll understand what UML really is, why it exists, and why experienced software engineers almost always visualize a system before implementing it.

What Is UML?

When beginners first hear UML (Unified Modeling Language), they often imagine a complicated collection of diagrams that only software architects create.

That's understandable—but it's also one of the biggest misconceptions.

UML is simply a visual language for describing software systems.

Just as English helps people communicate ideas through words, UML helps engineers communicate software designs through diagrams.

Notice something important.

UML doesn't design your software.

It gives you a common language to express your design clearly.

UML is to software design what blueprints are to architecture.

A blueprint doesn't build a house.

It helps everyone involved understand what is being built.

Software diagrams serve exactly the same purpose.

Why Not Just Read the Code?

A common question beginners ask is:

"If code already describes the system, why do we need diagrams?"

Because code answers a different question.

Code tells us:

How is something implemented?

Design diagrams tell us:

How is the system organized?

Imagine joining a new team.

Someone asks:

"How does an order move through our e-commerce platform?"

Would you rather read hundreds of classes across multiple services?

Or look at a simple visualization like this?

Customer
    │
    ▼
Shopping Cart
    │
    ▼
Order
    │
    ▼
Payment
    │
    ▼
Shipment

The diagram doesn't replace code.

It gives you the mental map before you dive into implementation.

That's why experienced engineers almost always sketch before they code.

Experienced Engineers Think in Models

One of the biggest mindset shifts in software engineering is realizing that senior engineers rarely think directly in code.

Instead, they think in models.

Before writing a single class, they're already asking questions like:

What are the important objects?
Which component owns this responsibility?
How do these objects interact?
Which business rules must never be violated?
How does an object evolve over time?

Only after those questions are answered does implementation begin.

Code is simply the final expression of an already well-understood design.

Why Visualization Matters

Imagine someone trying to explain an unfamiliar city.

They could spend ten minutes describing roads, intersections, and landmarks.

Or they could simply hand you a map.

Both contain the same information.

The map communicates it much faster.

Software diagrams work exactly the same way.

Instead of mentally assembling the system from dozens of source files, you immediately understand:

the important components
the relationships between them
how requests flow
how the system behaves

Visualization reduces cognitive load.

It allows everyone on the team to discuss the same picture instead of trying to imagine it individually.

Every Software System Has Two Different Views

One of the most useful mental models in software design is understanding that every system can be viewed from two perspectives.

1. The Static View

The static view answers questions like:

What objects exist?
How are they related?
What responsibilities do they have?

Think of it as the blueprint of your software.

Customer
    │
    ├── Address
    │
    └── Orders

Nothing is happening yet.

We're simply describing the structure.

2. The Dynamic View

Now imagine the customer places an order.

Suddenly, the system comes alive.

Customer
    │
    ▼
Order Service
    │
    ▼
Payment Service
    │
    ▼
Inventory Service

Now we're describing behavior instead of structure.

Great software engineers constantly switch between these two perspectives.

They understand both what exists and what happens.

UML Is Not a Single Diagram

Another common misconception is believing UML is just one diagram.

In reality, UML is a collection of diagrams, each designed to answer a different engineering question.

Throughout this series, we'll focus on the four diagrams every backend engineer should know.

Class Diagram

Answers:

What objects exist?
How are they related?

Sequence Diagram

Answers:

What happens when a request arrives?
Which object talks to which?

Use Case Diagram

Answers:

What should the system do?
Who interacts with it?

State Diagram

Answers:

How does an object evolve over time?
Which transitions are allowed?
What business rules control those transitions?

Each diagram gives you a different perspective of the same system.

Together, they provide a much clearer understanding than code alone.

A Real-World Example

Imagine you're building BookMyShow.

Different people on the team care about different questions.

A Product Manager asks:

"What can users do?"

A Backend Engineer asks:

"Which objects should exist?"

A Senior Engineer asks:

"How does seat booking flow through the system?"

A Domain Expert asks:

"What states can a booking move through?"

Notice that every question looks at the same system from a different angle.

No single diagram can answer all of them.

That's exactly why UML provides multiple views.

UML Is About Communication, Not Documentation

One of the biggest surprises for new developers is discovering that diagrams aren't primarily created for computers.

They're created for people.

Walk into almost any architecture discussion.

You'll rarely see perfectly formatted UML diagrams.

Instead, you'll see engineers drawing rough boxes and arrows on a whiteboard.

Why?

Because the goal isn't perfect notation.

The goal is shared understanding.

A rough sketch that everyone understands is far more valuable than a perfectly drawn diagram that nobody can follow.

This is an important mindset shift.

You're not learning UML to become a diagram expert.

You're learning UML to become a better communicator.

Common Beginner Misconceptions

"UML is only for architects."

Not anymore.

Modern backend engineers, staff engineers, and interview candidates regularly use simplified UML concepts to explain their designs.

"Real companies don't use UML."

Most companies don't create textbook-perfect UML diagrams.

Instead, they create simplified visual models inspired by UML.

The notation may be lighter.

The thinking is exactly the same.

"I'll just explain everything verbally."

That works for small systems.

As software grows, visual communication becomes dramatically more effective.

A one-minute sketch can replace ten minutes of explanation.

Weak Thinking vs Strong Thinking

Weak Thinking

What classes should I create?

Strong Thinking

What design am I trying to communicate?

Weak Thinking

Diagrams are documentation.

Strong Thinking

Diagrams are thinking tools.

Weak Thinking

Code explains everything.

Strong Thinking

Code explains implementation.

Diagrams explain design.

Interview Perspective

One pattern appears repeatedly in Low-Level Design interviews.

Many candidates immediately begin writing classes.

Experienced candidates don't.

They first spend a few minutes organizing the design.

Even if they don't formally draw UML, they're mentally answering questions like:

What is the system boundary?
Which objects exist?
How do requests flow?
How does the business lifecycle work?

Interviewers aren't evaluating your drawing skills.

They're evaluating whether you can organize complexity before jumping into implementation.

Visualization demonstrates structured thinking, which is exactly what interviewers are looking for.

What's Coming Next?

Now that we understand why software visualization exists, it's time to learn the diagrams themselves.

We'll begin with one of the most important diagrams in Low-Level Design:

Class Diagrams

You'll learn how experienced engineers model the structure of a system, identify relationships between objects, and build designs that remain maintainable as software grows.

The Most Important Insight

UML isn't about drawing diagrams.

It's about making software design visible.

Experienced engineers don't draw because diagrams are mandatory.

They draw because complex systems become significantly easier to understand, discuss, review, and improve when everyone is looking at the same picture.

That's the real purpose of visualization.

One-Line Takeaway

Great software isn't built by people who write code first—it is built by people who understand the design first, and visualization is how that understanding becomes shared.

LLD Domain Modeling: The Only Cheat Sheet You Actually Need (Interview + Real System Design)

Saras Growth Space — Sat, 18 Jul 2026 18:00:00 +0000

After going through entities, invariants, state machines, aggregates, bounded contexts, and full systems like Ride Sharing, BookMyShow, and Amazon Cart…

Everything compresses into one practical framework.

This is what experienced engineers actually use mentally during LLD.

The 10-Step Domain Modeling Checklist (Use This in Every Problem)

Whenever you see an LLD question, don’t jump to classes.

Run this checklist:

1. Understand the Real Flow

Ignore code.

Write the user journey:

Request → Process → Confirm → Complete

If you can’t explain flow, you can’t design system.

2. Identify Lifecycle Objects

Ask:

what changes over time?

These become Entities.

Examples:

Ride
Order
Booking
Cart

3. Separate Value Objects

Ask:

what is defined only by value?

Examples:

Money
Location
Quantity
Time

No identity. No lifecycle.

4. Extract Invariants (Most Critical Step)

Ask:

what must NEVER break?

Examples:

no double booking
no duplicate payment
valid state transitions

If you miss this step → design will fail later.

5. Define State Machines

Turn lifecycle into explicit states:

CREATED → PAID → COMPLETED

This prevents invalid behavior at system level.

6. Group by Consistency (Aggregates)

Ask:

what must always be consistent together?

Examples:

Show + Seats
Ride + lifecycle
Cart + pricing

This defines aggregate boundaries.

7. Separate Bounded Contexts

Ask:

where does meaning change?

Examples:

Cart ≠ Order
Ride ≠ Payment

This prevents model confusion at scale.

8. Assign Ownership Clearly

Ask:

who owns business rules?

Rules:

Entity → behavior + invariants
Service → orchestration

Never mix ownership.

9. Handle Failure Scenarios Early

Ask:

what if request is duplicated?
what if payment fails?
what if system retries?

Good models survive failures gracefully.

10. Only Then Define Classes

Now classes are NOT guessed.

They are derived from structure.

The Complete Mental Model

Everything you learned reduces to this:

Business Flow
   ↓
Invariants
   ↓
Entities + Value Objects
   ↓
State Machines
   ↓
Aggregates
   ↓
Bounded Contexts
   ↓
Services
   ↓
System Design

Why This Works in Interviews

Because interviewers are NOT testing:

syntax
design patterns
UML diagrams

They are testing:

how you think about business correctness under constraints.

This framework shows exactly that.

What Most Candidates Do Wrong

They start here:

classes → services → patterns

Instead of:

behavior → rules → structure → implementation

That inversion is the root cause of weak LLD answers.

The Real Definition of Good Domain Modeling

A good model is not:

complex
deeply abstract
heavily patterned

A good model is:

a structure that makes invalid business states hard to create.

Final Insight

If you remember only one thing from the entire series:

Domain Modeling is not about designing code structure — it is about designing systems that preserve business correctness as they evolve, fail, and scale.

That is the real skill behind strong Low-Level Design.

LLD Domain Modeling: Final Anti-Pattern Guide (How Good Designs Slowly Turn Bad)

Saras Growth Space — Sat, 18 Jul 2026 17:30:00 +0000

This is the final closure piece for Domain Modeling.

Because understanding “good design” is not enough.

You also need to understand:

how good designs fail over time.

Most real-world systems don’t collapse suddenly.

They degrade slowly through small modeling mistakes.

Anti-Pattern 1 — The God Object Evolution

It starts harmless:

UserService
OrderService
BookingService

Then slowly:

more methods get added
unrelated logic gets inserted
workflows accumulate inside one class

Eventually:

OrderService does everything

Symptoms:

impossible to test
impossible to understand
every change causes side effects

Root cause:

unclear responsibility boundaries

Anti-Pattern 2 — Anemic Domain Model

Entities look like:

class Order {
    String status;
    double amount;
}

All logic moves to services.

Result:

entities become passive data holders
business rules scatter everywhere
duplication increases

Problem:

behavior is separated from state

Anti-Pattern 3 — Invariants Scattered Everywhere

Instead of one place:

Order must be valid only if payment is successful

you find:

controllers checking rules
services repeating validations
helpers duplicating logic

Result:

inconsistent enforcement
bugs under edge cases

Root cause:

no central ownership of business rules

Anti-Pattern 4 — Wrong Aggregate Boundaries

Example:

Cart + Order + Payment mixed together

This causes:

shared state confusion
inconsistent updates
coupling explosion

Correct idea:

each aggregate must protect one consistency boundary

Anti-Pattern 5 — Over-Splitting Services

Opposite problem:

Instead of clarity:

CartService
CartItemService
CartPricingService
CartValidationService
CartCouponService

Now:

logic becomes fragmented
debugging becomes difficult
flow becomes unclear

Root cause:

splitting without thinking about ownership

Anti-Pattern 6 — Leaking Boundaries Across Contexts

Example:

Payment logic inside Order system
Inventory rules inside Cart system
Booking logic inside User system

This leads to:

tightly coupled systems
unpredictable changes
breaking changes across modules

Correct idea:

each bounded context must own its model fully

Anti-Pattern 7 — Primitive Obsession

Example:

String price
String location
String status

Instead of:

Money
Location
State

This causes:

missing validations
scattered rules
inconsistent usage

Root cause:

ignoring value objects

Anti-Pattern 8 — Overengineering Early

Beginners often add:

factories everywhere
interfaces everywhere
abstract layers everywhere

Even before understanding domain.

Result:

unnecessary complexity
slower development
harder debugging

Rule:

complexity must be earned, not assumed

Anti-Pattern 9 — No State Modeling

Instead of:

CREATED → PAID → SHIPPED

you see:

status = "anything"

This leads to:

invalid transitions
inconsistent states
hidden bugs

Root cause:

missing lifecycle thinking

Anti-Pattern 10 — Mixing Intent and Truth

Example:

Cart (intent)
Order (truth)

When mixed:

pricing becomes inconsistent
checkout becomes unreliable
state confusion increases

Correct separation:

intent vs committed state

The Hidden Pattern Behind All Failures

Almost every design failure comes from one root cause:

lack of clear ownership of business behavior

When ownership is unclear:

logic spreads
rules duplicate
states break
boundaries dissolve

How Strong Systems Avoid These Issues

Good systems consistently enforce:

clear entity responsibilities
centralized invariants
well-defined aggregates
strict bounded contexts
explicit state machines
minimal necessary services

Not because of theory.

But because:

they prevent long-term decay.

The Final Mental Model

Think of LLD like this:

If behavior has unclear ownership → design will degrade
If invariants are scattered → system will break
If boundaries are unclear → complexity will explode

Good design is simply:

preventing these failures from happening.

The Most Important Insight

Domain modeling is not about making systems complex.

It is about:

preventing complexity from spreading uncontrollably.

Because in real systems:

code evolves
teams change
requirements grow
edge cases appear

And only systems with strong modeling foundations survive this evolution cleanly.

That is the real purpose of Domain Modeling in LLD.

LLD Domain Modeling: The Complete Mental Framework (How to Think in Any System Design Problem)

Saras Growth Space — Sat, 18 Jul 2026 17:00:00 +0000

This is the final consolidation of everything in Domain Modeling.

If you understand this structure deeply, you don’t need to memorize LLD patterns anymore.

You can derive them.

The Core Idea of Domain Modeling

At its heart, domain modeling is simple:

Turn business behavior into structured, consistent, evolvable systems

Not classes. Not patterns. Not diagrams.

Behavior first.

Structure second.

The Complete Thinking Flow (Use This in Any LLD Problem)

When given any system design problem, follow this sequence:

1. Understand the Business Flow

Ask:

What is the user trying to do?
What is the step-by-step journey?

Example:

Request → Process → Confirm → Complete

Never start with classes.

2. Identify Lifecycle Objects (Entities)

Ask:

What things evolve over time?
What needs identity and tracking?

Examples:

Order
Ride
Booking
Cart

These become Entities.

3. Identify Value Objects

Ask:

What exists only as a description?

Examples:

Money
Location
Quantity
TimeSlot

No identity. No lifecycle.

4. Extract Invariants (Most Important Step)

Ask:

What must NEVER break?

Examples:

No double booking
No duplicate payment
Valid ride lifecycle

These define system correctness.

Everything else protects these rules.

5. Model State Transitions

Ask:

How does the entity evolve?

Example:

CREATED → PROCESSING → COMPLETED

State machines enforce correctness under real-world chaos.

6. Group by Consistency (Aggregates)

Ask:

What must stay consistent together?

Examples:

Show → Seats
Ride → Lifecycle
Cart → Pricing + Items

Aggregates protect invariants.

7. Separate Boundaries (Bounded Contexts)

Ask:

Where does meaning change?

Examples:

Cart ≠ Order
Ride ≠ Payment
Booking ≠ Inventory

Each context has its own model.

8. Assign Responsibilities (Entities vs Services)

Ask:

Who owns business rules?
Who orchestrates workflows?

Rules:

Entity → owns behavior + invariants
Service → coordinates flows

The Complete Mental Architecture

All concepts connect like this:

Business Behavior
   ↓
Invariants
   ↓
Entities + Value Objects
   ↓
State Machines
   ↓
Aggregates
   ↓
Bounded Contexts
   ↓
Services
   ↓
System Design

This is the real LLD structure.

How This Applies to Real Systems

BookMyShow

Entity → Show, Booking
Invariant → no double booking
Aggregate → Show
State → Seat lifecycle

Ride Sharing

Entity → Ride, Driver
Invariant → valid ride lifecycle
Aggregate → Ride
State → ride transitions

Amazon Cart

Entity → Cart, Order
Invariant → correct pricing
Aggregate → Cart
Context → Cart vs Order separation

The Biggest Mistake Beginners Make

They start here:

classes → code → patterns

Instead of:

behavior → invariants → structure → code

That inversion causes most confusion in LLD.

What Domain Modeling Actually Is

It is not:

UML diagrams
class creation
pattern application

It is:

a structured way of thinking about business correctness under real-world complexity

The Most Important Insight

Strong systems are not defined by:

number of classes
number of services
architecture style

They are defined by:

how well they preserve business correctness while evolving under change, failure, and scale.

Final Takeaway

If you remember only one thing:

Every good LLD design starts with behavior, and ends with boundaries that protect correctness.

Everything else is implementation detail.

That is the real foundation of Domain Modeling in System Design.

LLD Domain Modeling: The Final Layer — Bringing It All Together (How Real Systems Are Actually Structured)

Saras Growth Space — Sat, 18 Jul 2026 16:30:00 +0000

At this stage of domain modeling, we’ve explored:

entities vs value objects
invariants
state machines
aggregates
bounded contexts
system-level design (Ride Sharing, BookMyShow, Cart)

Now comes the final mental consolidation step:

how all these concepts actually fit together in a real system design.

Because individually, everything feels clear.

But together, they form a single unified thinking model.

The Core Truth of Domain Modeling

Real systems are not built from classes.

They are built from:

business behavior + consistency rules + lifecycle transitions

Everything else is a representation layer.

The Full Mental Pipeline (How Experts Think)

When given any LLD problem, experienced engineers internally follow this flow:

1. Understand behavior

What is the system doing?

2. Identify lifecycle objects

What evolves over time?

3. Extract invariants

What must NEVER break?

4. Define state transitions

How does each object evolve?

5. Group by consistency (Aggregates)

What must stay consistent together?

6. Separate boundaries (Bounded Contexts)

Where does meaning change?

7. Assign responsibilities

Who owns what logic?

This is not linear coding.

This is structured reasoning.

How All Concepts Fit Together

Let’s connect the dots.

Entities = Identity + Lifecycle

Ride, Order, Booking

They exist because:

they evolve
they must be tracked
they represent business truth

Value Objects = Meaning Without Identity

Money, Location, TimeSlot

They exist because:

they describe entities
they do NOT evolve independently

Invariants = Business Truth

No double booking
No duplicate payment
Valid ride lifecycle

They define correctness.

Everything exists to protect them.

State Machines = Lifecycle Control

CREATED → PAID → COMPLETED

They ensure:

controlled transitions
predictable behavior
failure safety

Aggregates = Consistency Boundaries

Show (BookMyShow)
Ride (Uber)
Cart (Amazon)

They ensure:

local consistency
atomic updates
rule enforcement

Bounded Contexts = Meaning Boundaries

Cart ≠ Order
Ride ≠ Payment
User Auth ≠ User Profile

They ensure:

models don’t collide
teams can scale
systems evolve independently

Services = Orchestration Layer

PaymentService, BookingService

They ensure:

workflows are executed
cross-aggregate coordination happens
domain logic remains clean

The Big Picture Architecture

Now everything connects:

Business Behavior
   ↓
Invariants + State Rules
   ↓
Entities + Value Objects
   ↓
Aggregates (Consistency Boundaries)
   ↓
Bounded Contexts (Meaning Boundaries)
   ↓
Services (Workflow Orchestration)
   ↓
System Design

This is the real LLD structure.

Not classes.

Not UML.

But layered domain thinking.

Why Most Beginners Get Lost

Because they start here:

classes → code → patterns

Instead of:

behavior → rules → structure → code

That inversion creates confusion.

What Real Systems Actually Are

At scale, systems are:

multiple state machines interacting
across bounded contexts
coordinated by services
while preserving invariants
under concurrency and failure

That is the real reality of production LLD.

Example — Everything Combined

Take BookMyShow:

Entities → Show, Seat, Booking
Value Objects → Money, SeatNumber
Invariants → no double booking
State Machine → Seat lifecycle
Aggregate → Show
Context → Booking vs Payment
Service → BookingService

Everything fits naturally into one structure.

The Most Important Insight

Domain Modeling is not a set of concepts.

It is a mental system architecture framework.

Once internalized, you stop thinking in:

classes

and start thinking in:

behavior
consistency
lifecycle
boundaries

Final Takeaway

Strong Low-Level Design is not about:

writing more code
using more patterns
creating more classes

It is about:

designing systems where business correctness survives growth, failures, concurrency, and change.

And domain modeling is the foundation that makes that possible.

This is where LLD stops being “coding design” and becomes real system thinking.

LLD Domain Modeling: How Real Systems Evolve Over Time (Versioning, Change & Refactoring Reality)

Saras Growth Space — Sat, 18 Jul 2026 16:00:00 +0000

One thing beginner LLD tutorials rarely show is this:

real systems never stay in their “initial design”.

They evolve constantly:

new features get added
business rules change
scale increases
edge cases appear
teams grow
boundaries shift

And slowly, even a “good design” starts to feel incomplete.

This is not failure.

This is normal system evolution.

The Real Nature of Software Systems

Software is not static.

It is:

a continuously changing model of business reality

So domain models must evolve too.

Why Good Designs Still Break Over Time

Even well-designed systems face issues like:

new requirements don’t fit existing model
aggregates become too large
services become overloaded
bounded contexts drift
invariants become more complex

Because:

business complexity grows faster than initial assumptions.

Step 1 — Recognize “Design Drift”

Design drift happens when:

original model no longer matches new business needs
logic starts leaking between boundaries
quick fixes accumulate
architecture becomes inconsistent

Symptoms:

too many exceptions in code
confusing responsibility ownership
growing number of hacks

Step 2 — Understand Why Refactoring Is Inevitable

Many beginners think:

“If I design well, I won’t need refactoring.”

But reality is:

no design is final.

Refactoring is not a mistake correction.

It is:

model correction
boundary adjustment
reality alignment

Step 3 — When to Refactor Domain Models

Refactor when:

1. Invariants Become Hard to Maintain

Rules are scattered or duplicated.

2. Aggregates Grow Too Large

One object starts doing too much.

3. Boundaries Stop Making Sense

Contexts start overlapping.

4. State Logic Becomes Complex

Too many edge cases in transitions.

Step 4 — Evolution Pattern: From Simple → Structured

Most systems evolve like this:

Phase 1: Simple Model

Few classes
Minimal logic
Everything in services

Phase 2: Growing Complexity

duplicated rules appear
services become large
state logic spreads

Phase 3: Domain Modeling Introduced

aggregates defined
invariants centralized
boundaries introduced

Phase 4: Continuous Refinement

boundaries adjusted
models split/merged
responsibilities corrected

Step 5 — Splitting vs Merging Models

As systems evolve:

Sometimes you split:

Cart → Cart + Pricing Context
User → Identity + Profile Context

Sometimes you merge:

too many tiny services
unnecessary abstraction layers

Good design is dynamic, not fixed.

Step 6 — Versioning Is Also Domain Modeling

When business changes:

pricing rules change
workflows evolve
new states are introduced

Instead of breaking everything:

you evolve the model carefully.

Example:

adding new Ride states
introducing new Order lifecycle rules

Step 7 — The Hard Truth About Real Systems

No matter how good your initial design is:

production systems always become more complex than expected.

Why?

real users behave unpredictably
edge cases are discovered late
business expands into new scenarios
integrations increase over time

So the goal is not:

perfect initial design

The goal is:

safe evolution over time

Step 8 — What Strong Engineers Optimize For

Not:

perfect structure

But:

adaptability
clarity under change
safe refactoring boundaries
isolated impact of changes

Because systems that cannot evolve:

eventually break under their own rigidity

Step 9 — The Role of Domain Modeling in Evolution

Domain modeling helps systems evolve by:

isolating invariants
defining ownership
controlling state transitions
separating bounded contexts

So changes don’t spread everywhere.

Weak LLD Thinking

“Let’s design it once and keep it fixed.”

Strong LLD Thinking

“Let’s design it so that change is safe and predictable.”

That is a completely different mindset.

The Most Important Insight

Domain models are not meant to be perfect.

They are meant to be:

continuously adjustable representations of evolving business reality.

And the strength of a system is not in how well it was designed initially.

It is in:

how safely it adapts
how cleanly it evolves
how well it contains change

Because in real Low-Level Design:

the best system is not the one that never changes — but the one that can change without breaking everything around it.

LLD Domain Modeling: How to Debug Your Design When It Feels “Wrong”

Saras Growth Space — Sat, 18 Jul 2026 15:30:00 +0000

Every engineer eventually hits this phase:

“My design looks okay… but something feels off.”

No compile errors.
No obvious bugs.
But still:

responsibilities feel scattered
services feel too big
entities feel too thin
logic feels duplicated
boundaries feel unclear

This is normal.

Because domain modeling is not about getting it right in one attempt.

It is about refining structure until the business behavior becomes clear.

Step 1 — Start With the Symptom, Not the Code

If your design feels wrong, don’t immediately rewrite everything.

First identify the symptom:

Common symptoms:

too many “Manager” services
logic repeated in multiple places
unclear ownership of rules
too many dependencies between modules
frequent “if-else explosion”

Each symptom points to a specific modeling issue.

Step 2 — Check If Invariants Are Scattered

Ask:

“Where are my business rules living?”

Bad sign:

Rules inside services + controllers + helpers

This leads to:

inconsistent behavior
duplicated validation
broken business guarantees

Good design:

invariants live close to the entity or aggregate root

Step 3 — Check Entity vs Service Confusion

A very common issue:

Entities become dumb:

only fields
no behavior

Services become overloaded:

all logic
all rules
all decisions

This creates:

Anemic Domain Model + Fat Services

Fix mindset:

Entity = owns behavior + protects state
Service = coordinates workflows

Step 4 — Check Your Aggregate Boundaries

Ask:

“What must stay consistent together?”

If your answer is unclear, you likely have:

wrong aggregates
or missing aggregates

Example problem:

Cart and Order sharing logic

This causes:

inconsistent pricing
unclear lifecycle ownership

Fix:

Cart = intent
Order = truth

Step 5 — Look for “Hidden Coupling”

Hidden coupling happens when:

one module depends on internal state of another
multiple services modify same data
business rules are duplicated across boundaries

This leads to fragile systems.

Strong design ensures:

each domain owns its own truth.

Step 6 — Validate State Transitions

Ask:

“Can my object reach invalid states easily?”

Bad sign:

status = "COMPLETED" directly assigned everywhere

Good sign:

completeRide() controls transition

If state changes are uncontrolled:

invariants break
bugs increase

Step 7 — Check If Boundaries Actually Mean Something

Bounded contexts should answer:

“Where does meaning change?”

Bad design:

same model reused everywhere
same object used in all flows

Good design:

Cart ≠ Order
Ride ≠ Payment
Booking ≠ Inventory

If everything shares one model:

boundaries are missing or weak

Step 8 — Ask the Most Important Question

When stuck, ask:

“Who owns this rule?”

Not:

where should I put this method?
which class should this go in?

Ownership clarifies:

structure
boundaries
responsibilities

Step 9 — Reduce, Don’t Just Add

When design feels messy, beginners add:

more classes
more services
more layers

But strong engineers often do the opposite:

they remove unnecessary abstractions first.

Simplification often reveals:

hidden responsibilities
correct boundaries
better aggregates

Step 10 — Compare Against Business Flow

Go back to:

real user journey

Then ask:

does my design match this flow?
does my state model reflect reality?
does ownership match business behavior?

If not → design drift has occurred.

Weak LLD Thinking

“Which pattern fixes this structure?”

Strong LLD Thinking

“Which part of the business is not correctly represented in my model?”

That shift is what debugging LLD is really about.

The Most Important Insight

Most broken designs are not technically wrong.

They are:

misaligned with the actual business behavior.

And debugging domain modeling is not about fixing code first.

It is about fixing:

ownership
boundaries
invariants
state transitions

Because in real Low-Level Design:

a good model doesn’t just work — it naturally prevents confusion, duplication, and invalid states.

LLD Domain Modeling: When NOT to Use Domain Modeling (Very Important Reality Check)

Saras Growth Space — Sat, 18 Jul 2026 15:00:00 +0000

Up to now, domain modeling may feel like the answer to everything:

entities
aggregates
invariants
bounded contexts
state machines

But strong engineers also know something equally important:

not every problem deserves deep domain modeling.

And over-applying it is one of the most common beginner mistakes.

The Mistake: Over-Engineering Everything

Beginners often take a simple problem like:

“ToDo app”

and design:

12 entities
5 aggregates
3 bounded contexts
complex state machines

This creates:

unnecessary complexity
slower development
harder debugging
confusion instead of clarity

Key Principle: Complexity Must Be Earned

Strong engineers follow this rule:

You don’t start with domain modeling complexity. You arrive at it when the problem demands it.

If the domain is simple:

keep it simple

If the domain is complex:

model it deeply

When You SHOULD Use Deep Domain Modeling

Use it when:

1. Strong Business Rules Exist

Example:

No double booking
No duplicate payment
Strict inventory control

If rules matter → model deeply.

2. State Changes Matter

Example:

ride lifecycle
order lifecycle
booking lifecycle

If lifecycle exists → state modeling is needed.

3. Concurrency Exists

Example:

multiple users booking same seat
multiple payments happening

If race conditions exist → aggregates matter.

4. Multiple Business Areas Interact

Example:

cart → payment → order → shipping

If workflows span domains → bounded contexts matter.

5. Failure Handling is Critical

Example:

payments can fail
retries matter
partial success exists

If failures matter → invariants matter deeply.

When You SHOULD NOT Over-Model

Avoid deep modeling when:

1. Simple CRUD Systems

Example:

admin panel
basic form submissions
static content systems

No need for:

aggregates
complex state machines

2. No Real Business Rules

If:

data is just stored and retrieved
no complex validation exists

Then:

domain modeling adds unnecessary overhead

3. No Lifecycle Complexity

If objects:

don’t evolve
don’t change state meaningfully

Then:

entities vs value objects distinction is minimal

4. No Concurrency Concerns

If:

single user usage
no race conditions

Then:

locking models are unnecessary

The Real Skill: Calibration

Strong engineers don’t ask:

“Can I apply domain modeling?”

Instead they ask:

“How much domain modeling does this problem actually need?”

That difference is crucial.

The Spectrum of Design Complexity

Think of system design as a spectrum:

Simple CRUD → Light structure → Full domain modeling → Distributed domain systems

Not everything belongs at the far right.

Example Comparison

ToDo App

Good design:

Task entity
basic status
simple service

No need for:

aggregates
bounded contexts

BookMyShow

Needs:

aggregates
state machines
concurrency control
invariants

Because complexity is real.

The Hidden Danger: Fake Complexity

Sometimes engineers:

apply patterns just to “look advanced”
add abstractions early
over-split services
create unnecessary boundaries

This leads to:

systems that are harder to understand than the problem itself

That is worse than simple design.

Strong LLD Thinking

“Start simple. Increase structure only when complexity demands it.”

Weak LLD Thinking

“I must use all concepts everywhere to show good design.”

Real Engineering Insight

Good architecture is not about:

maximizing abstraction
maximizing patterns
maximizing separation

It is about:

matching design complexity to domain complexity.

Final Mental Model

Before applying domain modeling, always ask:

Is the complexity in the business, or am I creating it in the design?

Because:

real complexity → must be modeled
artificial complexity → must be avoided

The Most Important Insight

Domain modeling is powerful, but not universal.

Its true purpose is:

to manage real-world business complexity, not to decorate simple systems with unnecessary structure.

And mastering LLD means knowing both:

when to model deeply
and when to keep things simple

Because the best design is not the most complex one.

It is the one that fits the problem exactly.