What Does "Domain" Actually Mean in Software Development?

If you ask ten developers what the word domain means, you'll probably get ten different answers. Some will say it's the database. Others will say it's the backend. I've even heard people use domain to refer to an entire application.

I used to think something similar. Then I started reading about Domain-Driven Design (DDD) and realized that I wasn't misunderstanding DDD—I was misunderstanding the word domain itself.

The Business Exists Before the Software

Imagine you're hired to build software for a hospital. Before you write a single line of code, the hospital already exists. Doctors treat patients, nurses schedule appointments, pharmacists dispense medication, and insurance companies process claims.

None of these concepts were created by your application. Your application simply learns how that world works and models it. That's the domain.

“

The software doesn't create the business. The business creates the need for the software.

A Better Way to Think About It

A domain is the real-world problem space your software is trying to solve.

Banking

• Accounts
• Transfers
• Loans
• Interest
• Fraud Detection

E-commerce

• Customers
• Shopping Carts
• Orders
• Inventory
• Shipments
• Refunds

Library

• Books
• Members
• Loans
• Reservations
• Late Fees

These concepts would still exist even if every server disappeared tomorrow. The software simply reflects that reality.

Where Developers Often Go Wrong

Most projects start by asking:

• Which database should we use?
• What tables do we need?
• Which REST endpoints should we expose?

Those are implementation questions. A better first question is:

“

How does this business actually work?

Data vs. Behavior

Instead of modeling:

• orders
• customers
• payments

Model the behavior:

• A customer places an order.
• An order reserves inventory.
• A payment authorizes the purchase.
• A shipment delivers the order.

Businesses care about behavior, not tables.

Why This Matters

When your code reflects database tables, business changes often spread across the system. When your code reflects the business, those rules have a natural place to live. That's the foundation of Domain-Driven Design.

Final Thoughts

Before there are entities, repositories, aggregates, APIs, or databases, there is a domain. Understand the business first. Everything else becomes much easier to design.