How to Model an E‑Commerce System with the 4+1 View Architecture

Background

The example targets a B2C e‑commerce platform that processes more than 100 k daily orders, peaks at 5 k QPS, and must support the Double‑11 promotion.

Logical View

The system boundary is illustrated with an ASCII diagram showing four core domains—User, Product, Order, and Payment—plus Marketing and external systems such as third‑party payment, logistics, SMS gateway, invoice and tax services.

┌─────────────────────────────────────────────────────┐
│                  电商系统                             │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌────────┐ │
│  │ 用户域  │  │ 商品域  │  │ 订单域  │  │ 支付域 │ │
│  └─────────┘  └─────────┘  └─────────┘  └────────┘ │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐              │
│  │ 营销域  │  │ 搜索域  │  │ 评价域  │              │
│  └─────────┘  └─────────┘  └─────────┘              │
│  外部系统： ├── 第三方支付 ├── 短信网关 ├── 第三方登录
│  外部系统： ├── 物流API ├── 发票系统 ├── 税务系统

Core functional modules are listed as follows:

User domain : registration/login (phone/email/third‑party), personal information, address management.

Product domain : product CRUD, shelf management, keyword search and category filtering.

Order domain : order creation, shopping cart, order query, cancellation, refund.

Payment domain : Alipay, WeChat, bank card integration.

Marketing domain : coupon issuance/usage, flash‑sale, group‑buy, full‑reduction activities.

Development View

The project uses a Maven multi‑module structure:

ecommerce/
├── e-commerce-parent/   # parent POM
│   └── pom.xml
├── e-commerce-common/   # shared utilities, exceptions, results
│   └── src/main/java/com/ecommerce/common/…
├── e-commerce-user/      # user service
├── e-commerce-product/   # product service
├── e-commerce-order/     # order service
├── e-commerce-payment/    # payment service
├── e-commerce-gateway/  # API gateway
└── e-commerce-search/    # search service

Dependency graph:

e-commerce-gateway → e-commerce‑xxx (user/product/order/payment) → e-commerce-common

Technology stack:

Language: Java 17

Framework: Spring Boot 3.0

Microservice framework: Spring Cloud 2022.0

Database: MySQL 8.0 (master‑slave)

Cache: Redis 7.0 (cluster)

Search: Elasticsearch 8.0

Message queue: Kafka 3.0 (3 brokers × 3 replicas)

Container: Docker 20.x

Orchestration: Kubernetes 1.26

Process View

Kubernetes deployment example for user‑service shows three pods, each with 20 worker threads, and an HPA that scales from 3 to 10 replicas based on CPU/memory.

┌─────────────────────────────────────────────────────────┐
│                  Kubernetes集群                          │
│  ┌─────────────────────────────────────────────────┐   │
│  │             Deployment: user-service              │   │
│  │  ┌─────────┐ ┌─────────┐ ┌─────────┐           │   │
│  │  │ Pod-1   │ │ Pod-2   │ │ Pod-3   │           │   │
│  │  │ Worker  │ │ Worker  │ │ Worker  │           │   │
│  │  │ Thread: │ │ Thread: │ │ Thread: │           │   │
│  │  │  20     │ │  20     │ │  20     │           │   │
│  │  └─────────┘ └─────────┘ └─────────┘           │   │
│  │  HPA: Min 3 → Max 10 │
└─────────────────────────────────────────────────────────┘

Thread‑pool configuration:

Service          Core   Max   Queue                Purpose
user-service    20     50    LinkedBlockingQueue   Business processing
order-service   30    100    ThreadPoolExecutor    Order processing
payment-service 10     30    SynchronousQueue      Payment callbacks

Asynchronous order handling example:

@Async
public void handleOrderCreated(Long orderId) {
    // 1. Send order‑created event to Kafka
    kafkaTemplate.send("order-topic", orderId);
    // 2. Decrease inventory (async via MQ)
    // 3. Send notification
    // 4. Update statistics
}

Physical View

Deployment architecture on Alibaba Cloud:

┌────────────────┐
│   Alibaba Cloud│
│   Public entry │
└───────┬────────┘
        │
   ┌────▼─────┐   ALB (cross‑AZ)
   │  Nginx x3 │
   └────┬─────┘
        │
   ┌────▼─────┐   VPC (private)
   │ K8s A/B/C │   (3 AZs, each with Gateway ×3, Service Pods ×9)
   └────┬─────┘
        │
   ┌────▼─────┐   RDS MySQL (master‑slave ×3)
   │   MySQL   │
   └────┬─────┘
        │
   ┌────▼─────┐   Redis Cluster ×6
   │   Redis   │
   └────┬─────┘
        │
   ┌────▼─────┐   Kafka (3 brokers ×3 replicas)
   │   Kafka   │
   └────┬─────┘
        │
   ┌────▼─────┐   Elasticsearch Cluster ×6
   │    ES     │
   └───────────┘

Server specifications (example): Nginx 2C4G ×3, Gateway 4C8G ×9, Business services 8C16G ×27, MySQL 16C64G ×3 (master‑slave), Redis 8C32G ×6 (cluster), Kafka 8C16G ×9 (3 brokers × 3 replicas), Elasticsearch 8C32G ×6 (3 nodes × 2 replicas).

Scenario View

Key scenarios with priority and involved services:

S001 – User registration/login (User service, Redis)

S002 – Product search (Search service, ES, Product service)

S003 – Product detail (Product service, Redis)

S004 – Cart management (Cart service, Redis)

S005 – Order creation (Order, Inventory, Payment services)

S006 – Order payment (Payment, Order services)

S007 – Order shipping (Order, Logistics services)

S008 – Order cancellation (Order, Inventory, Coupon services)

Order‑creation flow (simplified):

User → Front‑end → Gateway → Order‑service → Inventory‑service → UPDATE → OK
Order‑service → Payment‑service → INSERT → OK
… (subsequent steps for payment, status update, shipping message)

Inventory‑insufficient exception flow:

User → Front‑end → Gateway → Order‑service → Inventory‑service → UPDATE → FAIL (stock shortage)
Order‑service → rollback → FAIL → notify user

Conclusion

The four primary views—Logical, Process, Physical, and Scenario—are linked by the Scenario view, which validates the completeness of the architecture. The Development view ties everything together by showing how the code is organized, dependencies are managed, and the chosen technology stack supports the design.

Remember: The 4+1 view is a cohesive whole; the Scenario view is the red line that connects them.