Mastering Domain Modeling: A Practical Guide to Building Robust Business Models

Background

Software engineers abstract real‑world problems into computational models; a key step is domain modeling, which often starts simple but must evolve as business complexity grows.

Overall Idea

Modeling is a systematic engineering activity that can be split into four sub‑problems: functional requirement modeling, domain modeling, mapping domain models to code models, and deriving data models from code models.

Four Modeling Steps

Requirement model : clarify true user needs through communication with product and business stakeholders.

Domain model : extract domain concepts from the requirement model to support object‑oriented design.

Code model : design classes based on the domain model using OOP techniques.

Data model : use ER diagrams to represent storage relationships of the code model.

Example: User Purchases Product

Use Case

Users select multiple products, provide personal information, generate sub‑orders, calculate totals, choose a payment method, and complete or cancel the order.

Modeling Steps

Select nouns : Identify entities such as User, Product, Order, Sub‑order, Merchant, etc., and discard non‑domain items like "shopping app" or payment method details.

Find verbs : Actions like place order, summarize, save, pay, cancel are linked to the Order entity.

Add attributes : List properties for each entity (e.g., User: name, gender, phone; Product: name, price, category; Order: amount, time).

Connect relationships : Define how entities collaborate (e.g., User has Orders, Order contains Sub‑orders, Sub‑order contains Products).

Event Storming

Event storming is a workshop‑style technique that captures business events, commands, actors, and read models to achieve a shared understanding of the domain.

Event: an important, already occurred fact.

Command: the action triggered by an event.

Actor/Executor: the person, system, or scheduled task that triggers a command.

Read Model: the view used by executors to make decisions.

Four‑Color Modeling

Four‑color modeling extends event storming by classifying concepts into distinct archetypes, each represented by a color:

Moment‑Interval (MI): events occurring at a specific time or interval.

Part‑Place‑Thing (PPT): people, things, or places involved.

Role: the way an entity participates (e.g., customer, merchant).

Description (DESC): explanatory attributes of the above concepts.

Bounded Context & Pen‑Paper Method

The pen‑paper method (originating from ThoughtWorks) refines the four‑color model by identifying core domains, defining bounded contexts, and drawing aggregates on paper to avoid over‑design.

From Domain to Code

Domain classes map directly to code classes; attributes become fields; actions become methods; state machines become class state machines; relationships are expressed with UML class diagrams.

From Domain to Data

Entities become database tables; attributes become columns; one‑to‑many relationships become foreign keys (often logical); many‑to‑many relationships require join tables.

Model Quality Checklist

The domain model must reflect real‑world artifacts; avoid invented concepts.

Domain model is distinct from the DB schema; it describes business concepts, not storage details.

Relationships in the domain model should be stable; new requirements should add, not modify, existing links.

Continuous Iteration

Maintain a stable core model while allowing extensions; balance over‑design and under‑design; iterate by revisiting assumptions, refining concepts, and aligning the model with evolving business reality.