Domain Modeling

Imagine someone gives you this requirement:

Build an Online Shopping System.

Most developers immediately start creating classes:

class User{};
class Product{};
class Order{};

But an important question remains unanswered:

Why are these the right classes?

Or consider:

Build a Hotel Booking System.

Should we create:

class Hotel {};
class Room {};
class Reservation {};

Probably.

But how do we know?

How do we discover the important concepts?

How do we know which concepts deserve classes?

How do we know which concepts are merely attributes?

How do we model business rules correctly?

These questions are the purpose of Domain Modeling.

The Fundamental Idea

Before software exists:

Business Exists

Software is merely a model of that business.

Example:

A library exists even without software.

It already contains:

Books
Members
Loans
Reservations
Fines
Librarians

Software does not invent these concepts.

Software models them.

Definition

A Domain Model is:

A conceptual representation of important business concepts, relationships, behaviors, and rules.

Notce:

Conceptual Representation

Not:

Database Design
Code Design
API Design

Those come later.

Domain Modeling vs Database Modeling

Domain Modeling

Focuses on:

Business Concepts
Business Rules
Responsibilities
Relationships

Example:

Customer places Order

Database Modeling

Focuses on:

Tables
Columns
Indexes
Foreign Keys

Example:

customers
orders
order_items

Important Rule

Never start with database tables.

Start with business concepts.

Real-World Analogy

Imagine an architect designing a hospital.

They first think:

Patients

Doctors

Nurses

Departments

Appointments

Not:

Concrete
Steel
Electrical Wiring

Those details come later.

Software design works the same way.

Understanding the Domain

Before modeling:

You must understand the business.

Example:

Requirement:

Customers can order food from restaurants.

Restaurants prepare food.

Delivery partners deliver food.

Customers pay online.

Before creating classes:

Understand:

Who participates?

What happens?

What rules exist?

What terminology exists?

Step 1: Discover Domain Concepts

Let's analyze.

Requirement:

Customers place food orders.

Restaurants prepare food.

Delivery partners deliver food.

Potential concepts:

Customer
Restaurant
Order
DeliveryPartner
Payment

These become domain candidates.

Step 2: Separate Concepts from Attributes

Example:

Customer
Name
Phone Number
Address

Question:

Which are concepts?

Answer:

Customer

Question:

What are these?

Name
Phone Number
Address

Answer:

Attributes

Model:

class Customer
{
private:
    string name;
    string phone;
    string address;
};

Step 3: Discover Behaviors

Domain models are not just data.

We must identify behavior.

Cusotmer
	Place Order
	Cancel Order
	Update Address

Order
	Calculate Total
	Track Status
	Mark Paid
	
Restaurant
	Accept Order
	Reject Order
	Prepare Food

Behavior reveals responsibilities.