Bóc tách Hệ sinh thái: Chi tiết Service theo từng Domain

🇬🇧 Read the English version of this article on tanhdev.com

Answer-first: Bóc tách chi tiết 6 domain thương mại điện tử cốt lõi: Identity, Product Catalog, Inventory, Cart & Checkout, Order Management và Payment Gateway. Định nghĩa rõ ranh giới Bounded Context, lược đồ dữ liệu và hợp đồng API gRPC/Protobuf để loại bỏ phụ thuộc chéo giữa 21 Go microservices.

“Tại sao lại cần tới 21 services? Như thế chẳng phải là overkill (giết gà dùng đao mổ trâu) sao?”

Đây là câu hỏi phổ biến nhất mà tôi nhận được khi thảo luận về kiến trúc microservice viết bằng Golang mà chúng tôi đã xây dựng để xử lý khối lượng scale khổng lồ. Câu trả lời ngắn gọn là: Không, bởi vì Định luật Conway là có thật.

Khi bạn có nhiều squad (đội nhóm) cùng chọc vào một codebase, sự chồng chéo tính năng sẽ tạo ra ma sát. Bằng cách áp dụng nghiêm ngặt Thiết kế Hướng Domain (Domain-Driven Design - DDD), chúng tôi đã cắt nhỏ cục monolith thương mại điện tử của mình thành 6 Domain Nghiệp vụ (Business Domains) có tính liên kết nội bộ cao (highly cohesive) nhưng lại lỏng lẻo với bên ngoài (loosely coupled). Mỗi domain hoàn toàn tự cung tự cấp và sở hữu cơ sở dữ liệu Postgres của riêng nó.

Dưới đây là bản bóc tách kỹ thuật của 6 domain cốt lõi và các service nằm bên trong chúng.

1. Luồng Thương mại (The Commerce Flow)

Đây là trái tim giao dịch của toàn bộ nền tảng. Nếu domain này sập, dòng tiền sẽ ngừng chảy.

Checkout Service: Kẻ điều phối (The orchestrator). Nó quản lý các trạng thái biến động của giỏ hàng, xác thực lại giá từ catalog theo thời gian thực, và khởi tạo luồng Saga cho quá trình thanh toán.
Order Service: Service này xử lý nghiêm ngặt vòng đời sau-khi-checkout. Nó quyết định 8 trạng thái của một đơn hàng (Pending, Confirmed, Paid, Cancelled, v.v.) và đóng vai trò là điểm phát (publisher) sự kiện trung tâm.
Payment Service: Được bảo mật ở mức cao nhất. Tích hợp sâu với các API bên ngoài (Stripe, PayPal, VNPay, MoMo). Nó cũng chạy logic phát hiện GeoIP + VPN tự chế của chúng tôi để tự động chấm điểm gian lận (fraud scoring).

1.1 Sơ đồ Trình tự Checkout Liên-Domain (Cross-Domain Checkout Flow Sequence Diagram)

sequenceDiagram
    autonumber
    actor Client as Client / Storefront
    participant BFF as Gateway / BFF Layer
    participant Order as Order Service (Commerce)
    participant Inv as Warehouse Service (Logistics)
    participant Pay as Payment Service (Commerce)
    participant Ship as Shipping Service (Logistics)
    participant Bus as Event Mesh (Kafka / Dapr)

    Note over Client, Bus: Phase 1: Synchronous Order Initialization
    Client->>BFF: POST /api/v1/checkout (Cart Payload, Idempotency-Key)
    BFF->>Order: CreateOrder(CreateOrderRequest) [gRPC]
    Order->>Order: Write DB (Status: PENDING_PAYMENT, OCC Version: 1)
    Order-->>BFF: 201 Created (OrderID: `ord_98765`, Status: PENDING)
    BFF-->>Client: Checkout Initiated (OrderID: `ord_98765`)

    Note over Order, Bus: Phase 2: Async Choreography & Stock Reservation
    Order->>Bus: Publish `OrderCreatedEvent` (OrderID, SKU, Qty, UserID)
    Bus-->>Inv: Consume `OrderCreatedEvent`
    Inv->>Inv: Reserve Stock (IDEMPOTENT, OCC `version = version + 1`)
    alt Stock Available
        Inv->>Bus: Publish `InventoryReservedEvent` (OrderID, WarehouseID)
    else Stock Insufficient
        Inv->>Bus: Publish `InventoryReservationFailedEvent` (OrderID, Reason)
        Bus-->>Order: Consume `InventoryReservationFailedEvent`
        Order->>Order: Update DB (Status: CANCELLED_OUT_OF_STOCK)
    end

    Note over Pay, Bus: Phase 3: Payment Gateway Execution
    Bus-->>Pay: Consume `InventoryReservedEvent`
    Pay->>Pay: Execute Fraud Scoring & Call External Gateway (Stripe/VNPay)
    alt Payment Succeeded
        Pay->>Bus: Publish `PaymentProcessedEvent` (OrderID, TxID, Status: SUCCESS)
    else Payment Declined / Timeout
        Pay->>Bus: Publish `PaymentProcessedEvent` (OrderID, Status: FAILED)
        Bus-->>Inv: Consume `PaymentProcessedEvent` (FAILED)
        Inv->>Inv: Compensate: Release Stock Reservation
        Bus-->>Order: Consume `PaymentProcessedEvent` (FAILED)
        Order->>Order: Update DB (Status: PAYMENT_FAILED)
    end

    Note over Ship, Bus: Phase 4: Order Confirmation & Fulfillment Hand-off
    Bus-->>Order: Consume `PaymentProcessedEvent` (SUCCESS)
    Order->>Order: Update DB (Status: CONFIRMED)
    Order->>Bus: Publish `OrderConfirmedEvent` (OrderID, CustomerID)
    
    Bus-->>Ship: Consume `OrderConfirmedEvent`
    Ship->>Ship: Generate Tracking Label (3PL API) & Write DB
    Ship->>Bus: Publish `ShipmentDispatchedEvent` (TrackingNo, Carrier)

1.2 Async Domain Event Contracts (Protobuf v3 & JSON Schema)

Để đảm bảo tính toàn vẹn dữ liệu khi giao tiếp bất đồng bộ qua Kafka/Dapr Event Mesh, các domain event được định nghĩa bằng Protobuf v3 và JSON Schema tiêu chuẩn.

1. Protobuf v3 Definition: `checkout_events.proto`

syntax = "proto3";

package ecommerce.events.v1;

option go_package = "github.com/microservices/proto/events/v1;eventsv1";

import "google/protobuf/timestamp.proto";

// Enum defining canonical payment processing statuses
enum PaymentStatus {
  PAYMENT_STATUS_UNSPECIFIED = 0;
  PAYMENT_STATUS_SUCCESS = 1;
  PAYMENT_STATUS_FAILED = 2;
  PAYMENT_STATUS_REQUIRES_ACTION = 3;
}

// Published by Order Service when a new checkout is committed to DB
message OrderCreatedEvent {
  string event_id = 1;
  string order_id = 2;
  string customer_id = 3;
  int64 total_amount_cents = 4;
  string currency = 5; // ISO 4217 (e.g. "USD", "VND")
  string idempotency_key = 6;
  
  message OrderItem {
    string sku_id = 1;
    int32 quantity = 2;
    int64 unit_price_cents = 3;
  }
  
  repeated OrderItem items = 7;
  google.protobuf.Timestamp created_at = 8;
}

// Published by Warehouse / Inventory Service upon successful stock isolation
message InventoryReservedEvent {
  string event_id = 1;
  string reservation_id = 2;
  string order_id = 3;
  string warehouse_id = 4;
  
  message ReservedItem {
    string sku_id = 1;
    int32 quantity = 2;
  }
  
  repeated ReservedItem items = 5;
  int64 expires_at_unix = 6;
  google.protobuf.Timestamp reserved_at = 7;
}

// Published by Payment Service after calling payment gateway
message PaymentProcessedEvent {
  string event_id = 1;
  string payment_id = 2;
  string order_id = 3;
  string transaction_reference = 4;
  int64 amount_cents = 5;
  string payment_provider = 6; // e.g., "STRIPE", "MOMO", "VNPAY"
  PaymentStatus status = 7;
  string failure_reason = 8;
  google.protobuf.Timestamp processed_at = 9;
}

2. JSON Event Payload Schema: `OrderCreatedEvent.json`

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "OrderCreatedEvent",
  "type": "object",
  "required": ["event_id", "order_id", "customer_id", "total_amount_cents", "currency", "idempotency_key", "items", "created_at"],
  "properties": {
    "event_id": { "type": "string", "format": "uuid" },
    "order_id": { "type": "string", "pattern": "^ord_[a-zA-Z0-9]+$" },
    "customer_id": { "type": "string", "format": "uuid" },
    "total_amount_cents": { "type": "integer", "minimum": 0 },
    "currency": { "type": "string", "minLength": 3, "maxLength": 3 },
    "idempotency_key": { "type": "string", "format": "uuid" },
    "items": {
      "type": "array",
      "minItems": 1,
      "items": {
        "type": "object",
        "required": ["sku_id", "quantity", "unit_price_cents"],
        "properties": {
          "sku_id": { "type": "string" },
          "quantity": { "type": "integer", "minimum": 1 },
          "unit_price_cents": { "type": "integer", "minimum": 0 }
        }
      }
    },
    "created_at": { "type": "string", "format": "date-time" }
  }
}

2. Sản phẩm & Nội dung (Product & Content)

Một domain thiên về đọc (read-heavy) được tinh chỉnh để có độ trễ cực thấp.

Catalog Service: Nguồn chân lý duy nhất (Single source of truth) cho PIM (Quản lý Thông tin Sản phẩm). Nó xử lý các cấu trúc EAV (Entity-Attribute-Value) phức tạp, danh mục phân cấp sâu, và dữ liệu thương hiệu.
Pricing Service: Bóc tách logic giá cả biến động ra khỏi Catalog. Nó quản lý việc quy đổi đa tiền tệ, tính thuế, và các tầng ghi đè giá (ví dụ: giá riêng theo từng Kho so với giá mặc định của SKU).
Promotion Service: Chứa logic BOGO (Mua 1 tặng 1), tính toán giảm giá theo bậc (tiered discount), và sổ cái ghi nhận việc đổi mã coupon.

3. Vận chuyển & Kho bãi (Logistics)

Di chuyển các thực thể vật lý trong thế giới thực.

Warehouse Service: Một hệ thống WMS (Quản lý kho) thu nhỏ. Nó xử lý việc phân mảnh tồn kho đa điểm, định vị vị trí kệ hàng (bin locators), và theo dõi các sự kiện giữ chỗ tồn kho (stock-reservation) có tính lũy đẳng (idempotent) để đảm bảo việc bán lố (overselling) là bất khả thi về mặt toán học.
Fulfillment Service: Quyết định luồng thao tác vận hành nội bộ: Nhặt hàng (Picking), Đóng gói (Packing), và Bàn giao (Hand-off).
Shipping Service: Một tác tử vùng biên (edge-agent) giao tiếp trực tiếp với các đơn vị vận chuyển vật lý (Grab, GHTK, v.v.) và chuẩn hóa các webhook cập nhật hành trình để các hệ thống nội bộ chỉ phải tiêu hóa một định dạng payload tiêu chuẩn duy nhất.

4. Hậu mãi (Post-Purchase)

Nơi việc giữ chân khách hàng diễn ra.

Return Service: Một domain phức tạp đến đáng sợ. Nó phải điều phối việc nhập lại hàng với Warehouse, kích hoạt các lệnh gọi gRPC hoàn tiền (refund) về Payment service, và xử lý việc tạo mã RMA (Return Merchandise Authorization).
Loyalty Service: Một database có thông lượng (throughput) cao, chuyên nuốt các sự kiện ‘đơn hàng hoàn tất’ để tăng hạng điểm và điều phối việc trả hoa hồng giới thiệu thông qua pattern Transactional Outbox.

5. Danh tính & Quyền truy cập (Identity & Access)

Những kẻ gác cổng.

Auth Service: Cấp phát các chuỗi RS256 JWT không lưu trạng thái (stateless), xử lý các luồng OAuth2 (Google/Github), và quản lý logic MFA (Xác thực 2 yếu tố) hoàn toàn bằng Redis caching.
User Service & Customer Service: Được chia tách rạch ròi để các công cụ phân quyền nội bộ RBAC dành cho nhân viên (User) không làm vấy bẩn dữ liệu profile khách hàng bên ngoài và các database phân tích giá trị vòng đời khách hàng (Customer).

6. Vận hành Nền tảng (Platform Operations)

Các tiện ích hạ tầng dùng chung mà các domain khác phụ thuộc rất nhiều vào.

Gateway Service: Điểm đầu vào thực hiện việc định tuyến API, giới hạn tốc độ (rate-limiting) toàn cầu, và dập cầu dao điện (circuit breaking).
Search Service: Một read-model theo pattern CQRS được xây dựng trên Elasticsearch. Nó tiêu thụ các sự kiện Dapr từ Catalog và Pricing service để tạo ra các document phẳng (flattened) đã được index, cho tốc độ truy vấn nhanh như chớp.
Analytics & Notification: Các quan sát viên thụ động (Passive observers). Chúng ngồi ở cuối các hàng đợi Dapr, chờ đợi các sự kiện hệ thống báo về để cập nhật dashboard kinh doanh hoặc bắn tin nhắn/email chăm sóc khách hàng qua SendGrid/Twilio.

7. Chiến lược Phân lập Cơ sở dữ liệu & Database Schemas (Database Isolation Strategy)

Để loại bỏ hoàn toàn rủi ro trở thành một “Distributed Monolith”, mỗi domain service sở hữu một instance cơ sở dữ liệu PostgreSQL độc lập (hoặc schema rạch ròi không có cross-database user grant):

Order Service: Phụ trách order_db (Biên giao dịch ACID cho vòng đời đơn hàng).
Inventory Service: Phụ trách inventory_db (Kho khóa bất đồng bộ Optimistic Concurrency Locking tránh bán lố).
Payment Service: Phụ trách payment_db (Sổ cái kiểm toán cho các giao dịch cổng thanh toán bên ngoài).

Các truy vấn JOIN trực tiếp giữa các cơ sở dữ liệu của dịch vụ khác nhau bị nghiêm cấm hoàn toàn.

7.1 Order Service (`order_db`) PostgreSQL DDL & GORM Structs

-- PostgreSQL DDL for order_db
CREATE TABLE orders (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    order_number VARCHAR(64) NOT NULL UNIQUE,
    customer_id UUID NOT NULL,
    status VARCHAR(32) NOT NULL DEFAULT 'PENDING_PAYMENT',
    total_amount_cents BIGINT NOT NULL CHECK (total_amount_cents >= 0),
    currency VARCHAR(3) NOT NULL DEFAULT 'USD',
    idempotency_key VARCHAR(128) NOT NULL UNIQUE,
    version INT NOT NULL DEFAULT 1,
    created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE order_items (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    order_id UUID NOT NULL REFERENCES orders(id) ON DELETE CASCADE,
    sku_id VARCHAR(64) NOT NULL,
    quantity INT NOT NULL CHECK (quantity > 0),
    unit_price_cents BIGINT NOT NULL CHECK (unit_price_cents >= 0),
    created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX idx_orders_customer_status ON orders(customer_id, status);
CREATE INDEX idx_orders_created_at ON orders(created_at DESC);

// Package models in Order Service
package models

import (
	"time"

	"github.com/google/uuid"
)

type OrderStatus string

const (
	StatusPendingPayment OrderStatus = "PENDING_PAYMENT"
	StatusConfirmed      OrderStatus = "CONFIRMED"
	StatusPaymentFailed  OrderStatus = "PAYMENT_FAILED"
	StatusCancelled      OrderStatus = "CANCELLED"
)

type Order struct {
	ID               uuid.UUID   `gorm:"type:uuid;primaryKey;default:gen_random_uuid()"`
	OrderNumber      string      `gorm:"type:varchar(64);uniqueIndex;not null"`
	CustomerID       uuid.UUID   `gorm:"type:uuid;index:idx_orders_customer_status;not null"`
	Status           OrderStatus `gorm:"type:varchar(32);index:idx_orders_customer_status;not null;default:'PENDING_PAYMENT'"`
	TotalAmountCents int64       `gorm:"type:bigint;not null"`
	Currency         string      `gorm:"type:varchar(3);not null;default:'USD'"`
	IdempotencyKey   string      `gorm:"type:varchar(128);uniqueIndex;not null"`
	Version          int32       `gorm:"type:int;not null;default:1"` // Optimistic Concurrency Control
	Items            []OrderItem `gorm:"foreignKey:OrderID;constraint:OnDelete:CASCADE;"`
	CreatedAt        time.Time   `gorm:"type:timestamptz;not null;default:CURRENT_TIMESTAMP"`
	UpdatedAt        time.Time   `gorm:"type:timestamptz;not null;default:CURRENT_TIMESTAMP"`
}

type OrderItem struct {
	ID             uuid.UUID `gorm:"type:uuid;primaryKey;default:gen_random_uuid()"`
	OrderID        uuid.UUID `gorm:"type:uuid;not null;index"`
	SkuID          string    `gorm:"type:varchar(64);not null"`
	Quantity       int32     `gorm:"type:int;not null"`
	UnitPriceCents int64     `gorm:"type:bigint;not null"`
	CreatedAt      time.Time `gorm:"type:timestamptz;not null;default:CURRENT_TIMESTAMP"`
}

7.2 Inventory Service (`inventory_db`) PostgreSQL DDL & GORM Structs

-- PostgreSQL DDL for inventory_db
CREATE TABLE stock_levels (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    warehouse_id UUID NOT NULL,
    sku_id VARCHAR(64) NOT NULL,
    available_qty INT NOT NULL CHECK (available_qty >= 0),
    reserved_qty INT NOT NULL CHECK (reserved_qty >= 0),
    version INT NOT NULL DEFAULT 1,
    created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
    CONSTRAINT uk_warehouse_sku UNIQUE (warehouse_id, sku_id)
);

CREATE TABLE stock_reservations (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    order_id UUID NOT NULL,
    warehouse_id UUID NOT NULL,
    sku_id VARCHAR(64) NOT NULL,
    reserved_qty INT NOT NULL CHECK (reserved_qty > 0),
    status VARCHAR(32) NOT NULL DEFAULT 'RESERVED',
    expires_at TIMESTAMPTZ NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX idx_reservations_order_id ON stock_reservations(order_id);
CREATE INDEX idx_reservations_status_expires ON stock_reservations(status, expires_at);

// Package models in Inventory Service
package models

import (
	"time"

	"github.com/google/uuid"
)

type StockLevel struct {
	ID           uuid.UUID `gorm:"type:uuid;primaryKey;default:gen_random_uuid()"`
	WarehouseID  uuid.UUID `gorm:"type:uuid;uniqueIndex:uk_warehouse_sku;not null"`
	SkuID        string    `gorm:"type:varchar(64);uniqueIndex:uk_warehouse_sku;not null"`
	AvailableQty int32     `gorm:"type:int;not null"`
	ReservedQty  int32     `gorm:"type:int;not null"`
	Version      int32     `gorm:"type:int;not null;default:1"` // OCC guard against overselling
	CreatedAt    time.Time `gorm:"type:timestamptz;not null;default:CURRENT_TIMESTAMP"`
	UpdatedAt    time.Time `gorm:"type:timestamptz;not null;default:CURRENT_TIMESTAMP"`
}

type StockReservation struct {
	ID          uuid.UUID `gorm:"type:uuid;primaryKey;default:gen_random_uuid()"`
	OrderID     uuid.UUID `gorm:"type:uuid;index;not null"`
	WarehouseID uuid.UUID `gorm:"type:uuid;not null"`
	SkuID       string    `gorm:"type:varchar(64);not null"`
	ReservedQty int32     `gorm:"type:int;not null"`
	Status      string    `gorm:"type:varchar(32);not null;default:'RESERVED'"`
	ExpiresAt   time.Time `gorm:"type:timestamptz;not null"`
	CreatedAt   time.Time `gorm:"type:timestamptz;not null;default:CURRENT_TIMESTAMP"`
}

7.3 Payment Service (`payment_db`) PostgreSQL DDL & GORM Structs

-- PostgreSQL DDL for payment_db
CREATE TABLE payment_transactions (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    order_id UUID NOT NULL UNIQUE,
    idempotency_key VARCHAR(128) NOT NULL UNIQUE,
    amount_cents BIGINT NOT NULL CHECK (amount_cents >= 0),
    currency VARCHAR(3) NOT NULL DEFAULT 'USD',
    provider VARCHAR(32) NOT NULL,
    provider_tx_id VARCHAR(128),
    status VARCHAR(32) NOT NULL DEFAULT 'PENDING',
    failure_reason TEXT,
    raw_response JSONB,
    created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);

// Package models in Payment Service
package models

import (
	"time"

	"github.com/google/uuid"
	"gorm.io/datatypes"
)

type PaymentTransaction struct {
	ID             uuid.UUID      `gorm:"type:uuid;primaryKey;default:gen_random_uuid()"`
	OrderID        uuid.UUID      `gorm:"type:uuid;uniqueIndex;not null"`
	IdempotencyKey string         `gorm:"type:varchar(128);uniqueIndex;not null"`
	AmountCents    int64          `gorm:"type:bigint;not null"`
	Currency       string         `gorm:"type:varchar(3);not null;default:'USD'"`
	Provider       string         `gorm:"type:varchar(32);not null"`
	ProviderTxID   *string        `gorm:"type:varchar(128)"`
	Status         string         `gorm:"type:varchar(32);not null;default:'PENDING'"`
	FailureReason  *string        `gorm:"type:text"`
	RawResponse    datatypes.JSON `gorm:"type:jsonb"`
	CreatedAt      time.Time      `gorm:"type:timestamptz;not null;default:CURRENT_TIMESTAMP"`
	UpdatedAt      time.Time      `gorm:"type:timestamptz;not null;default:CURRENT_TIMESTAMP"`
}

Giá trị của Sự chia tách

Nhìn vào hệ sinh thái qua lăng kính của 6 domain này, 21 services không còn giống như một mớ hỗn độn — chúng trông giống một dây chuyền nhà máy được tổ chức quy củ. Một con bug ở hệ thống Review không thể kéo sập hệ thống Payment. Một đợt bùng nổ traffic cục bộ trong mùa Flash Sale đồng nghĩa với việc chúng ta chỉ cần đẻ thêm 10 pods cho Order và Checkout services mà không phải đốt tiền để scale các service đang nằm im như Catalog hay Platform. Đây chính là giá trị thực tiễn cấp độ doanh nghiệp của Domain-Driven Design!

Bài viết này là một phần của series composable commerce. Để xem bản vẽ toàn hệ thống, kiến trúc luồng traffic, và lý luận đằng sau các quyết định thiết kế, hãy bắt đầu tại Bản vẽ Hệ thống Thương mại điện tử 21-Service: Kiến trúc & Luồng Dữ liệu.

🤝 Kết nối với tôi

Bạn đang gặp phải những thách thức tương tự về kiến trúc hệ thống, mở rộng quy mô (scaling) hay dịch chuyển (migration)? Hãy kết nối với tôi trên LinkedIn, theo dõi GitHub của tôi, hoặc gửi một email để trao đổi nhé.

🔗 Đọc thêm các chuyên đề & Series liên quan:

Series: System Design Architecture — Hệ thống kiến trúc phân tán quy mô lớn.
Series: E-Commerce Order Allocation — Thiết kế hệ thống phân bổ đơn hàng và tồn kho đa kho.
Kiến trúc Microservices Golang & DDD
Triển khai Agentic AI Swarm trong Production với OpenClaw & LiteLLM
Kiến trúc Microservices Golang gRPC: Protobuf, TLS & Middleware

❓ Câu Hỏi Thường Gặp (FAQ)

Q1: Bóc tách Hệ sinh thái: Chi tiết Service theo từng Domain giải quyết vấn đề cốt lõi nào trong kiến trúc hệ thống?

How 21 Go microservices partition across 6 DDD domains: service ownership, database boundaries, and async event contracts for a production e-commerce platform.

Q2: Những lưu ý quan trọng nhất khi triển khai thực tế là gì?

Cần chú trọng phân tầng ranh giới trách nhiệm (bounded context), thiết lập cơ chế fallback dự phòng, và giám sát chặt chẽ qua metrics OpenTelemetry để phát hiện sớm các điểm nghẽn.

Q3: Làm sao để kiểm thử và đánh giá hiệu quả sau khi áp dụng?

Áp dụng kiểm thử tải (load test), benchmark độ trễ P95/P99 trước và sau triển khai, kết hợp tracing phân tán để xác minh tính ổn định dưới tải cao.

1. Luồng Thương mại (The Commerce Flow)#

1.1 Sơ đồ Trình tự Checkout Liên-Domain (Cross-Domain Checkout Flow Sequence Diagram)#

1.2 Async Domain Event Contracts (Protobuf v3 & JSON Schema)#

1. Protobuf v3 Definition: checkout_events.proto#

2. JSON Event Payload Schema: OrderCreatedEvent.json#

2. Sản phẩm & Nội dung (Product & Content)#

3. Vận chuyển & Kho bãi (Logistics)#

4. Hậu mãi (Post-Purchase)#

5. Danh tính & Quyền truy cập (Identity & Access)#

6. Vận hành Nền tảng (Platform Operations)#

7. Chiến lược Phân lập Cơ sở dữ liệu & Database Schemas (Database Isolation Strategy)#

7.1 Order Service (order_db) PostgreSQL DDL & GORM Structs#

7.2 Inventory Service (inventory_db) PostgreSQL DDL & GORM Structs#

7.3 Payment Service (payment_db) PostgreSQL DDL & GORM Structs#

Giá trị của Sự chia tách#