Break complex systems into bounded contexts with DDD. Map business capabilities to service boundaries, define ubiquitous language, assess cohesion/coupling. Use when refactoring monoliths or designing new architectures.
From system-designnpx claudepluginhub sethdford/claude-skills --plugin architect-system-designThis skill is limited to using the following tools:
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Details PluginEval's skill quality evaluation: 3 layers (static, LLM judge), 10 dimensions, rubrics, formulas, anti-patterns, badges. Use to interpret scores, improve triggering, calibrate thresholds.
Systematically decompose complex systems using Domain-Driven Design: identify business capabilities, define bounded contexts, evaluate cohesion/coupling, design integration patterns.
You are decomposing a system into services or modules. Your role is to:
Good decomposition follows business domains, not technology layers. Anti-pattern: UserService, OrderService, PaymentService (implementation detail names) instead of Auth Realm, Commerce Hub, Payment Platform (domain names).
Based on Eric Evans' Domain-Driven Design and Sam Newman's Building Microservices:
Ask: "What does the business do?"
Example (E-commerce):
Each capability can become a bounded context.
For each capability, establish boundary with explicit name and responsibilities.
Example:
Auth Realm (Authentication)
- User registration, login, session management
- Produces: authenticated identity tokens
- Language: User, Credential, Session, Auth Token
Commerce Hub (Order Processing)
- Order creation, cart management, inventory
- Consumes: Auth tokens
- Produces: Order events
- Language: Order, Customer, Product, Cart, OrderItem
Payment Platform (Payment Processing)
- Payment processing, refunds, accounting
- Consumes: Order events
- Produces: Payment status events
- Language: Payment, Invoice, Transaction, Settlement
Define key terms within each context:
Auth Realm:
- "User" = identity with credentials
- "Session" = authenticated connection
Commerce Hub:
- "Order" = customer purchase request
- "Customer" = entity that places orders (different from Auth's User)
Payment Platform:
- "Invoice" = billable entity (different from Order)
- "Settlement" = final accounting status
Contexts use same words differently. Clear boundaries prevent confusion.
Cohesion (within context):
Coupling (between contexts):
Synchronous (API call):
Asynchronous (event):
Boxes = Contexts, Arrows = Synchronous calls, Events = Asynchronous communication.
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Auth Realm │ │Commerce Hub │ │ Payment │
│ │ │ │ │ Platform │
│ - Register │──API───│ - Order │───API──│ - Process │
│ - Login │ │ creation │ │ payment │
│ - Session │ │ - Inventory │ │ - Refund │
└──────────────┘ │ │ └──────────────┘
│ Order Created│
│ Event ────────────────┐
└──────────────┘ │
Event Handler
(async payment)
When decomposing, deliver:
Monolith: Single "UserService" handling everything (100K lines)
Issues:
Decomposition:
Bounded Contexts:
1. Auth Realm: Registration, login, profiles
2. Commerce Hub: Orders, cart, inventory
3. Payment Platform: Payments, invoicing, settlements
4. Analytics: User behavior, metrics
Cohesion Scores:
Coupling Analysis:
Integration:
Commerce Hub: POST /payment/charge with Order details
Response: Payment ID + status
On failure: Rollback order
Analytics: Subscribes to "OrderCreated" event
No coupling: Order doesn't wait for analytics