domain-model-boundaries-mapper（领域模型边界映射器）

Domain Model & Boundaries Mapper

Map domain boundaries and ownership using Domain-Driven Design.

Domain Map Template

# Domain Map: E-Commerce Platform

## Bounded Contexts

### 1. Customer Management

**Core Domain:** User accounts, profiles, preferences
**Owner:** Customer Team
**Ubiquitous Language:**

- Customer: Registered user with account
- Profile: Customer personal information
- Preferences: User settings and choices

**Entities:**

- Customer (id, email, name)
- Address (id, customer_id, street, city)
- PaymentMethod (id, customer_id, type, token)

**Bounded Context Diagram:**

┌─────────────────────────────┐ │ Customer Management │ │ ┌─────────┐ ┌──────────┐ │ │ │Customer │ │ Address │ │ │ └─────────┘ └──────────┘ │ │ ┌─────────────────────┐ │ │ │ Payment Method │ │ │ └─────────────────────┘ │ └─────────────────────────────┘

### 2. Order Management
**Core Domain:** Order processing, fulfillment
**Owner:** Orders Team
**Ubiquitous Language:**
- Order: Purchase request with line items
- LineItem: Product quantity in order
- Fulfillment: Physical delivery of order

**Entities:**
- Order (id, customer_id, status, total)
- LineItem (id, order_id, product_id, quantity)
- Shipment (id, order_id, tracking_number)

### 3. Product Catalog
**Core Domain:** Product information, inventory
**Owner:** Catalog Team
**Ubiquitous Language:**
- Product: Sellable item
- SKU: Stock keeping unit
- Inventory: Available stock

**Entities:**
- Product (id, name, price, description)
- Inventory (sku, quantity, warehouse_id)

## Context Relationships

Customer Management ──────▶ Order Management (customer_id)

Product Catalog ──────▶ Order Management (product_id)

Order Management ──────▶ Fulfillment (order events)

## Anti-Corruption Layers

### Order Management → Customer Management
**Problem:** Orders need customer data but shouldn't depend on Customer domain model

**Solution:** Customer Adapter

// Order domain's view of customer interface CustomerForOrder { id: string; shippingAddress: Address; billingAddress: Address; }

// Adapter translates Customer domain to Order domain class CustomerAdapter { async getCustomerForOrder(customerId: string): Promise<CustomerForOrder> { const customer = await customerService.getCustomer(customerId); return { id: customer.id, shippingAddress: this.toOrderAddress(customer.defaultShippingAddress), billingAddress: this.toOrderAddress(customer.defaultBillingAddress), }; } }

## Dependency Map

┌──────────────┐ │ Customer │ └──────┬───────┘ │ ▼ ┌──────────────┐ ┌────────────┐ │ Orders │─────▶│ Products │ └──────┬───────┘ └────────────┘ │ ▼ ┌──────────────┐ │ Fulfillment │ └──────────────┘

**Dependency Rules:**

- Customer has no dependencies
- Orders depends on Customer (read) and Products (read)
- Fulfillment depends on Orders (events)

## Interface Contracts

### Customer Management → Orders

// Public interface exposed by Customer domain interface CustomerService { getCustomer(id: string): Promise<Customer>; getCustomerAddresses(id: string): Promise<Address[]>; }

// Events published interface CustomerUpdated { customerId: string; email: string; name: string; }

### Product Catalog → Orders

interface ProductService { getProduct(id: string): Promise<Product>; checkAvailability(sku: string, quantity: number): Promise<boolean>; reserveInventory(items: ReservationRequest[]): Promise<Reservation>; }

## Refactor Recommendations

### Problem 1: Tight Coupling

**Current:** Orders directly queries Customer database **Issue:** Breaks bounded context, creates coupling **Recommendation:** Use Customer API instead

// ❌ Before: Direct database access const customer = await db.customers.findById(customerId);

// ✅ After: API call through adapter const customer = await customerAdapter.getCustomerForOrder(customerId);

### Problem 2: Shared Models

**Current:** Same `User` model used across contexts **Issue:** Changes in one context affect others **Recommendation:** Separate models per context

// Customer context interface Customer { id: string; email: string; profile: CustomerProfile; preferences: CustomerPreferences; }

// Order context (different model!) interface OrderCustomer { id: string; shippingAddress: Address; billingAddress: Address; }

### Problem 3: God Service

**Current:** `OrderService` handles orders, inventory, payments, shipping **Issue:** Single service owns too much **Recommendation:** Extract bounded contexts

- OrderService: Order lifecycle
- InventoryService: Stock management
- PaymentService: Payment processing
- FulfillmentService: Shipping

## Strategic Design Patterns

### Pattern 1: Shared Kernel

**When:** Two contexts must share some code **Example:** Common value objects (Money, Address)

// Shared kernel (minimal!) class Money { constructor(public amount: number, public currency: string) {} }

### Pattern 2: Customer/Supplier

**When:** One context depends on another **Example:** Orders (customer) depends on Products (supplier)

- Supplier defines interface
- Customer adapts to their needs

### Pattern 3: Published Language

**When:** Many contexts need same data **Example:** Product events

interface ProductCreated { productId: string; name: string; price: Money; publishedAt: Date; }

## Migration Strategy

### Phase 1: Identify Boundaries

- Map existing code to domains
- Identify coupling points
- Document dependencies

### Phase 2: Define Interfaces

- Design APIs between contexts
- Create adapter layers
- Define event contracts

### Phase 3: Decouple

- Replace direct DB access with APIs
- Introduce anti-corruption layers
- Separate models per context

### Phase 4: Extract Services (optional)

- Move contexts to separate services
- Implement API gateways
- Set up event bus

## Best Practices

1. **Ubiquitous language**: Same terms in code and domain
2. **Bounded contexts**: Clear boundaries, separate models
3. **Context maps**: Document relationships
4. **Anti-corruption layers**: Protect domain integrity
5. **Event-driven**: Loose coupling via events
6. **Separate databases**: Context owns its data

## Output Checklist

- Bounded contexts identified (3-7)
- Core domain vs supporting domains
- Ubiquitous language defined per context
- Entity/aggregate definitions
- Context relationship diagram
- Dependency map
- Interface contracts defined
- Anti-corruption layers designed
- Refactor recommendations
- Migration strategy