Agent skill

domain-model-boundaries-mapper

Identifies domain modules, ownership boundaries, dependencies, and interfaces using Domain-Driven Design principles. Provides domain maps, bounded contexts, refactor recommendations. Use for "DDD", "domain modeling", "bounded contexts", or "service boundaries".

View SKILL.md on GitHub Repository
Stars 23
Forks 2

Install this agent skill to your Project

npx add-skill https://github.com/patricio0312rev/skills/tree/main/architecture/domain-model-boundaries-mapper

SKILL.md

Domain Model & Boundaries Mapper

Map domain boundaries and ownership using Domain-Driven Design.

Domain Map Template

markdown
# 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
```typescript
// 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

typescript
// 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

typescript
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

typescript
// ❌ 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

typescript
// 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)

typescript
// 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

typescript
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

Recommended Agent Skills

Expand your agent's capabilities with these related and highly-rated skills.

patricio0312rev/skills

rate-limiting-abuse-protection

Implements rate limiting and abuse prevention with per-route policies, IP/user-based limits, sliding windows, safe error responses, and observability. Use when adding "rate limiting", "API protection", "abuse prevention", or "DDoS protection".

23 2
Explore
patricio0312rev/skills

rbac-permissions-builder

Implements role-based access control with permission matrix, route guards, policy functions, and UI permission hints. Provides middleware/guards, helper utilities, test suggestions, and permission checking patterns. Use when building "RBAC", "permissions", "access control", or "authorization".

23 2
Explore
patricio0312rev/skills

websocket-realtime-builder

Implements real-time features using WebSockets with Socket.io, rooms, authentication, and reconnection handling. Use when users request "real-time updates", "WebSocket", "Socket.io", "live chat", or "push notifications".

23 2
Explore
patricio0312rev/skills

webhook-receiver-hardener

Secures webhook receivers with signature verification, retry handling, deduplication, idempotency keys, and error responses. Provides verification code, dedupe storage strategy, runbook for incidents. Use when implementing "webhooks", "webhook security", "event receivers", or "third-party integrations".

23 2
Explore
patricio0312rev/skills

auth-module-builder

Implements secure authentication patterns including login/registration, session management, JWT tokens, password hashing, cookie settings, and CSRF protection. Provides auth routes, middleware, security configurations, and threat model documentation. Use when building "authentication", "login system", "JWT auth", or "session management".

23 2
Explore
patricio0312rev/skills

rest-to-graphql-migrator

Migrates REST APIs to GraphQL incrementally with schema stitching, REST datasources, and gradual endpoint migration. Use when users request "migrate to GraphQL", "REST to GraphQL", "GraphQL wrapper", or "API modernization".

23 2
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results