How to Build Effective Domain Models for E‑Commerce Systems
This article explains the purpose, definition, and step‑by‑step process of creating domain models for e‑commerce shopping flows, covering concept identification, relationship mapping, state modeling, class and state diagrams, model review, and introduces the accompanying conceptual architecture visuals.
1. Domain Model
Definition: A tool for exploring the problem domain that expresses core business concepts and the relationships between them.
Purpose:
Facilitates communication by providing domain vocabulary and concept relationships.
Forms the business core after refinement.
Can be mapped to a data model with little modification.
Reflects the essence of entities, influencing system boundaries, reusability, and scalability.
Process: Identify domain concepts, identify domain relationships, identify domain states, then model the domain (using class diagrams, state diagrams, and domain model reviews).
Expression methods: Class diagram, state diagram.
Related concepts: Domain glossary.
Participants: Domain experts, customers, requirement analysts, architects, system analysts, etc.
2. Requirement Background – E‑Commerce Shopping Flow (Simplified)
Members can purchase products; different member levels have different prices.
Purchasing generates a customer order that may contain multiple items.
Members can choose online payment or cash on delivery.
After delivery, members can evaluate their purchase experience.
Step 1: Identify Domain Concepts
Member (ordinary, platinum, diamond), Price (varies by member), Order (purchase proof), Product (item sold), Online Payment, Cash on Delivery, Delivery, Evaluation.
Step 2: Identify Domain Relationships
Member ↔ Order: one‑to‑many.
Product ↔ Price: one‑to‑many.
Order ↔ Product: one‑to‑many.
Product ↔ Evaluation: one‑to‑many.
Order ↔ Delivery: one‑to‑one.
Generalization relationships: Member categories (ordinary, platinum, diamond); Payment methods (online, offline).
Step 3: Identify Domain States (using Order as example)
States: Initial, Pending Payment, Pending Shipment, Received, Evaluated, Refunding, Refunded, Cancelled.
State transitions:
Initial → Pending Payment → Pending Shipment → Received → Evaluated.
Pending Shipment → Refunding → Refunded.
Pending Payment → Cancelled.
Step 4: Domain Modeling
Class Diagram (core fields and relationships) – see image below.
State Diagram – see image below.
Step 5: Domain Model Review
Invite customers, domain experts, architects, industry leaders, and management. Follow a checklist and plan to present, discuss, evaluate, and record results.
Key points:
Prepare review materials and pre‑communicate.
Invite the right participants (mandatory, optional, unnecessary).
Control the review process and record notes.
Obtain outcomes: approved, rejected, or need revision.
Post‑review actions: modify, re‑review, obtain signatures.
2. Conceptual Architecture
Illustrative diagrams of the system’s conceptual architecture are shown below.
3. Article Summary
4. Next Preview
Part 6 will cover system design details: architecture refinement, architecture views, and architecture documentation.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
ITFLY8 Architecture Home
ITFLY8 Architecture Home - focused on architecture knowledge sharing and exchange, covering project management and product design. Includes large-scale distributed website architecture (high performance, high availability, caching, message queues...), design patterns, architecture patterns, big data, project management (SCRUM, PMP, Prince2), product design, and more.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.