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 RelationshipsCustomer 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