MBC CQRS Serverless Development
Build serverless applications using CQRS (Command Query Responsibility Segregation) pattern on AWS with NestJS, DynamoDB event sourcing, and multi-tenant data isolation.
What This Skill Does
This skill configures your AI coding assistant to follow MBC CQRS Serverless project conventions when working with serverless AWS applications built on the CQRS pattern. It provides context from architecture documentation, enforces naming conventions, and guides code generation following event sourcing and multi-tenant best practices.
Instructions for AI Agent
Context Files (Read-Only)
Load these files for context before making changes (do not edit):
`CLAUDE.md` - Project overview`AGENTS.md` - Agent configuration`llms.txt` - LLM-specific guidance`README.md` - Project documentation`CONTRIBUTING.md` - Contribution guidelines`docs/architecture/system-overview.md` - System architecture`docs/architecture/cqrs-flow.md` - CQRS flow diagrams`packages/core/README.md` - Core package documentationFiles to Ignore
Never read or modify:
`node_modules/**``dist/**``coverage/**``*.log``.git/**``package-lock.json`Code Generation Rules
#### Language & Type Safety
Write all documentation and comments in EnglishUse TypeScript with strict mode enabledEnsure type safety across all boundaries#### Architecture Patterns
**CQRS Separation:**
Commands handle write operations (mutations)Queries handle read operations (data retrieval)Commands and queries must never cross boundaries**Event Sourcing:**
Store events in DynamoDBRebuild state from event historyEvents are immutable facts**Multi-Tenant Isolation:**
Partition key prefix: `{tenantCode}#RESOURCE_TYPE`Sort key format: `RESOURCE_TYPE#{id}`Always validate tenant access in handlers#### Naming Conventions
**Commands:**
Format: `{Action}{Resource}Command`Examples: `CreateUserCommand`, `UpdateOrderCommand`, `DeleteProductCommand`**Events:**
Format: `{Resource}{PastTenseAction}Event`Examples: `UserCreatedEvent`, `OrderUpdatedEvent`, `ProductDeletedEvent`**Handlers:**
Format: `{Action}{Resource}Handler`Examples: `CreateUserHandler`, `UpdateOrderHandler`, `DeleteProductHandler`**DTOs:**
Input: `{Action}{Resource}Dto`Output: `{Resource}ResponseDto`Examples: `CreateUserDto`, `UserResponseDto`#### Module Structure
Organize code following this structure:
```
src/module/
├── commands/ # Command classes and handlers
├── queries/ # Query classes and handlers
├── dto/ # Data transfer objects
├── entities/ # Domain entities
├── controllers/ # API controllers
└── module.ts # NestJS module definition
```
#### DynamoDB Key Design
**Partition Key (PK):**
Format: `{tenantCode}#RESOURCE_TYPE`Example: `TENANT001#USER`**Sort Key (SK):**
Format: `RESOURCE_TYPE#{id}`Example: `USER#123e4567-e89b-12d3-a456-426614174000`Always use this pattern for multi-tenant data isolation.
#### Testing Standards
**Unit Tests:**
Use Jest testing frameworkMock AWS SDK clients with `aws-sdk-client-mock`Test all handlers and servicesAim for high code coverage**E2E Tests:**
Test full request/response cycles through controllersValidate multi-tenant isolationTest error scenarios**Test Structure:**
```typescript
describe('CreateUserHandler', () => {
it('should create user and emit event', async () => {
// Arrange: setup mocks
// Act: execute command
// Assert: verify results and events
});
});
```
Quality Checks
**After Making Changes:**
1. Run linter: `npm run lint`
2. Run tests: `npm test`
3. Verify no build errors
4. Check that conventions are followed
**Do Not Auto-Commit:**
Commits should be explicit and reviewedChanges must pass lint and test commands firstCode Review Checklist
Before completing any task, verify:
[ ] TypeScript strict mode compliance[ ] CQRS boundaries respected (command vs query)[ ] Multi-tenant isolation implemented (PK/SK pattern)[ ] Naming conventions followed[ ] Events are immutable and well-named[ ] Tests written and passing[ ] Documentation updated if needed[ ] No sensitive data in logs or errorsUsage Examples
**Example 1: Creating a new resource**
```
User: "Add a new Product resource with create, update, and list operations"
AI will generate:
commands/create-product.command.tscommands/update-product.command.tsqueries/list-products.query.tsdto/create-product.dto.tsdto/update-product.dto.tsdto/product-response.dto.tsentities/product.entity.tscontrollers/product.controller.tsEvents: ProductCreatedEvent, ProductUpdatedEventTests for all handlers```
**Example 2: Implementing multi-tenant query**
```
User: "Add a query to get all orders for a specific tenant"
AI will generate:
queries/get-tenant-orders.query.ts with proper PK/SK filteringHandler that validates tenant accessDTO with tenant validationUnit tests with aws-sdk-client-mock```
**Example 3: Adding event handler**
```
User: "Create an event handler for when a user is created"
AI will generate:
Event handler following CQRS patternEvent subscriber registered in moduleTests verifying event emission and handling```
Important Notes
This project uses event sourcing - events are the source of truthAlways respect multi-tenant boundaries - never leak data across tenantsCommands and queries must remain separate per CQRS principlesDynamoDB key design is critical for performance and isolationAll AWS SDK calls should be properly mocked in testsFollow the established module structure for consistency