Domain-Driven Design

DDD stands for Domain-Driven Design. It’s a way of designing software by focusing on the business domain — the real-world problem the software is trying to solve — rather than just the technology.

🔹 Domain

The domain is the business problem space — what your software is about.
It’s the core logic and rules that represent how the real world works for your business.

Example domains:

• Banking (Accounts, Transactions, Loans)
• E-commerce (Orders, Products, Customers)
• Healthcare (Patients, Appointments, Prescriptions)

So, the domain is a conceptual area — not just code.

🔹 Module

A module is a technical organization of code — like a folder or package in your project.

In DDD, we often map each major domain area (or subdomain) into a separate module in the codebase for clarity.

💡 Example: E-commerce System

Business Domains:

• Ordering
• Inventory
• Shipping

Code Structure (modules):

src/
 ├── ordering/       ← Domain module for "Ordering"
 │    ├── domain/
 │    │    ├── order.py
 │    │    ├── customer.py
 │    │    └── events.py
 │    ├── application/
 │    │    ├── order_service.py
 │    ├── infrastructure/
 │    │    ├── order_repository.py
 │    └── __init__.py
 │
 ├── inventory/
 │    ├── domain/
 │    └── ...
 │
 ├── shipping/
 │    ├── domain/
 │    └── ...

src/
 ├── ordering/       ← Domain module for "Ordering"
 │    ├── domain/
 │    │    ├── order.py
 │    │    ├── customer.py
 │    │    └── events.py
 │    ├── application/
 │    │    ├── order_service.py
 │    ├── infrastructure/
 │    │    ├── order_repository.py
 │    └── __init__.py
 │
 ├── inventory/
 │    ├── domain/
 │    └── ...
 │
 ├── shipping/
 │    ├── domain/
 │    └── ...

So:

• The domain layer (inside each module) holds the entities, value objects, and business rules.
• The module groups all the code for that domain (domain + application + infrastructure).

🔸 In summary: