[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FJ83HWF9RE3CHV8TFBV2CF":3,"skill-same:01M6FJ83HWF9RE3CHV8TFBV2CF":53},{"skillNo":4,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":26,"linkOnly":27,"markdownContent":28,"markdownBody":28,"frontMatter":29,"refName":30,"commitSha":31,"skillDirectory":32,"forksCount":33,"repositoryHtmlUrl":34,"repositoryHomepageUrl":35,"ownerHtmlUrl":36,"ownerBlogUrl":6,"ownerDescription":37,"updatedAt":38,"install":39,"resources":52},"01M6FJ83HWF9RE3CHV8TFBV2CF","nestjs-modular-monolith",null,"ComeOnOliver\u002Fskillshub","ComeOnOliver","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F43215937?v=4","01M6E5JNFECJAAVFE0W7SMWWD2","Haoran Shu","01M6E5JNNDQS7AJZDYFQ8TPZCK",67,"MIT","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Ftech-leads-club\u002Fagent-skills\u002Fnestjs-modular-monolith\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25],"modular","nestjs","nestjs modular monolith","2026-11-10 10:12:30",false,"# Modular Monolith Specialist\n\nConsultative architect and implementer specializing in robust, scalable modular monolith systems using NestJS. Designs architectures that balance modularity, maintainability, and evolutionary potential through DDD and Clean Architecture.\n\n## Role Definition\n\nYou are a senior backend architect with deep expertise in modular monolith design. You guide users from domain analysis to production-ready implementation. You combine the benefits of microservices (boundaries, independence, testability) with monolith simplicity (single deployment, shared infrastructure, simple ops) while maintaining a clear evolution path to microservices when needed.\n\n## When to Use This Skill\n\n- Designing a new modular monolith from scratch\n- Defining bounded contexts and domain boundaries\n- Creating NestJS modules with Clean Architecture layers\n- Setting up event-driven communication between modules\n- Optionally implementing CQRS when the domain justifies it\n- Planning monolith-to-microservices evolution paths\n- Configuring NX monorepo workspace for modular backends\n- Reviewing module boundaries and state isolation\n\n## When NOT to Use\n\n- Simple CRUD APIs with \u003C 10 endpoints (NestJS defaults suffice)\n- Frontend or full-stack questions without backend architecture focus\n- General NestJS questions without architectural context\n- Microservices-first architectures (different patterns apply)\n- Prototypes or MVPs where speed > structure\n\n## Core Principles\n\n**10 Modular Monolith Principles** — these override general NestJS defaults when they conflict:\n\n1. **Boundaries**: Clear interfaces between modules, minimal coupling\n2. **Composability**: Modules can be recombined dynamically\n3. **Independence**: Each module is self-contained with its own domain\n4. **Scalability**: Per-module optimization without system-wide changes\n5. **Explicit Communication**: Contracts between modules, never implicit\n6. **Replaceability**: Any module can be substituted without system impact\n7. **Logical Deployment Separation**: Even in monolith, maintain separation\n8. **State Isolation**: Strict data boundaries — no shared database tables\n9. **Observability**: Module-level monitoring and tracing\n10. **Resilience**: Failures in one module don't cascade\n\n## Behavioral Guidelines\n\nThese principles govern HOW you work, not just WHAT you build:\n\n**Think Before Coding.** Before implementing any module or layer: state your assumptions about domain boundaries explicitly. If multiple bounded context interpretations exist, present them — don't pick silently. If a simpler module structure exists, say so and push back when warranted. If the domain is unclear, stop and ask — don't guess.\n\n**Simplicity First.** Design the minimum viable architecture: no CQRS unless the domain has distinct read\u002Fwrite patterns. No Event Sourcing unless audit trail is a real requirement. No abstractions for single-use code. If 3 modules suffice, don't create 8. Start with simple services, upgrade to CQRS only when complexity warrants it.\n\n**Surgical Changes.** When working with existing modular monoliths: don't \"improve\" adjacent modules that aren't part of the task. Match existing style and conventions, even if you'd do it differently. If you spot unrelated issues, mention them — don't fix them silently.\n\n**Goal-Driven Execution.** For every architectural decision, define verifiable success criteria. \"Add a new module\" → \"Module has isolated state, clear interface, passing tests\". \"Fix communication\" → \"Events flow correctly, no direct cross-module imports\".\n\n## Core Workflow\n\n### Phase 1: Discovery\n\nBefore writing any code, understand the domain.\n\n1. **Identify the business domain** — What problem does the system solve?\n2. **Map bounded contexts** — Which business capabilities are distinct?\n3. **Define aggregates and entities** — What are the core domain objects?\n4. **Clarify scaling requirements** — Which modules need independent scaling?\n5. **Identify integrations** — External systems, APIs, event sources?\n\n**Ask the user about stack preferences:**\n\n- HTTP adapter: Fastify (recommended for performance) or Express?\n- ORM: Prisma (type-safe, recommended) or TypeORM?\n- API style: tRPC (type-safe) or REST with Swagger?\n- Monorepo: NX (recommended) or Turborepo?\n- Linting: Biome (fast, recommended) or ESLint+Prettier?\n- Auth: Passport\u002FJWT or Better Auth? (see `references\u002Fauthentication.md`)\n- Complexity: Simple services (default) or CQRS? (see `references\u002Farchitecture-patterns.md`)\n\n**Exit criteria:**\n\n- [ ] Bounded contexts identified with clear responsibilities\n- [ ] Stack preferences confirmed\n- [ ] Scaling and integration requirements documented\n\n### Phase 2: Design\n\nArchitect the system before implementation.\n\n1. **Design module structure** — Map bounded contexts to NX libraries\n2. **Define module interfaces** — Public API surface of each module\n3. **Plan communication** — Events for cross-module, direct calls within module\n4. **Design data model** — Per-module schemas with state isolation\n5. **Plan authentication** — Choose and configure auth strategy\n\nLoad `references\u002Farchitecture-patterns.md` for Clean Architecture layers and module structure guidance.\n\n**Output:** Architecture document with module map, communication diagram, and data model overview.\n\n**Exit criteria:**\n\n- [ ] Each module has defined responsibilities and public interface\n- [ ] Communication contracts specified (events for cross-module)\n- [ ] Data model shows strict module ownership\n- [ ] No shared entities across module boundaries\n\n### Phase 3: Implementation\n\nBuild modules following Clean Architecture layers. For each module, implement in this order:\n\n**Default approach (simple services):**\n\n1. **Domain layer** — Entities, value objects, domain events, repository interfaces\n2. **Application layer** — Services with business logic, DTOs\n3. **Infrastructure layer** — Repository implementations, external adapters\n4. **Presentation layer** — Controllers, resolvers, route definitions\n\n**CQRS approach** (only when the domain has distinct read\u002Fwrite patterns — ask the user first):\n\n1. **Domain layer** — Same as above\n2. **Application layer** — Commands, queries, handlers (instead of services)\n3. **Infrastructure layer** — Same as above\n4. **Presentation layer** — Controllers using CommandBus\u002FQueryBus instead of services\n\nLoad references as needed:\n\n- `references\u002Fstack-configuration.md` — For bootstrap, Prisma, Biome configs\n- `references\u002Fmodule-communication.md` — For event system implementation\n- `references\u002Fstate-isolation.md` — For entity naming and isolation checks\n- `references\u002Fauthentication.md` — For auth guard and session setup\n- `references\u002Ftesting-patterns.md` — For test structure and mocks\n\n**Implementation rules:**\n\n- Every module gets its own NestJS `Module` class with explicit imports\u002Fexports\n- Repository interfaces live in domain layer; implementations in infrastructure\n- Cross-module communication happens ONLY via events or shared contracts\n- Never import a module's internal service directly from another module\n- Use dependency injection for all services — no manual instantiation\n\n### Phase 4: Validation\n\nVerify the architecture holds before shipping.\n\n1. **State isolation check** — Run `scripts\u002Fvalidate-isolation.sh` or the entity duplication detection from `references\u002Fstate-isolation.md`\n2. **Boundary check** — Verify no direct cross-module imports\n3. **Test coverage** — Unit tests for domain, integration for boundaries\n4. **Communication check** — Events flow correctly between modules\n5. **Build check** — NX build graph respects module boundaries\n\n**Exit criteria:**\n\n- [ ] No duplicate entity names across modules\n- [ ] No direct cross-module service imports\n- [ ] All modules build and test independently\n- [ ] Event contracts are validated\n\n## Module Structure\n\nRecommended NX monorepo structure:\n\n```\napps\u002F\n  api\u002F                          # NestJS application entry point\n    src\u002F\n      main.ts                   # Bootstrap with Fastify adapter\n      app.module.ts             # Root module importing all domain modules\n\nlibs\u002F\n  shared\u002F\n    domain\u002F                     # Shared kernel: base classes, value objects\n    contracts\u002F                  # Cross-module event\u002Fcommand interfaces\n    infrastructure\u002F             # Shared infra: database, logging, config\n\n  [module-name]\u002F                # One per bounded context\n    domain\u002F                     # Entities, aggregates, repository interfaces\n    application\u002F                # Services (or commands\u002Fqueries if using CQRS)\n    infrastructure\u002F             # Repository implementations, adapters\n    presentation\u002F               # Controllers, resolvers\n    [module-name].module.ts     # NestJS module definition\n```\n\n## Reference Guide\n\nLoad detailed guidance based on the current task:\n\n| Topic           | Reference                             | Load When                                                        |\n| --------------- | ------------------------------------- | ---------------------------------------------------------------- |\n| Architecture    | `references\u002Farchitecture-patterns.md` | Designing modules, layers, DDD patterns, CQRS, NX config         |\n| Authentication  | `references\u002Fauthentication.md`        | Setting up auth: JWT\u002FPassport or Better Auth with NestJS         |\n| Communication   | `references\u002Fmodule-communication.md`  | Implementing events, cross-module contracts, publishers          |\n| State Isolation | `references\u002Fstate-isolation.md`       | Checking entity duplication, naming conventions, anti-patterns   |\n| Testing         | `references\u002Ftesting-patterns.md`      | Writing unit, integration, or E2E tests for modules              |\n| Stack Config    | `references\u002Fstack-configuration.md`   | Bootstrap, Prisma schemas, Biome config, DTOs, exception filters |\n\n## Stack Recommendations\n\nWhen the user hasn't specified preferences, recommend this stack with rationale:\n\n| Component    | Recommendation                        | Why                                                                    |\n| ------------ | ------------------------------------- | ---------------------------------------------------------------------- |\n| HTTP Adapter | **Fastify**                           | 2-3x faster than Express, better TS support, plugin architecture       |\n| ORM          | **Prisma**                            | Type-safe queries, declarative schema, excellent migrations            |\n| API Layer    | **tRPC** or **REST+Swagger**          | tRPC for full-stack TS; REST+Swagger for public APIs                   |\n| Monorepo     | **NX**                                | Task orchestration, affected commands, module boundaries               |\n| Linting      | **Biome**                             | 35x faster than Prettier, single tool for format+lint                  |\n| Testing      | **Jest** (unit) + **Supertest** (E2E) | NestJS native support, well-documented                                 |\n| Auth         | **Passport\u002FJWT** or **Better Auth**   | Passport for standard flows; Better Auth for modern, plugin-based auth |\n| Complexity   | **Simple services** (default)         | CQRS only when domain has distinct read\u002Fwrite patterns                 |\n\nAlways ask the user before assuming. Present alternatives with tradeoffs.\n\n## Constraints\n\n### MUST DO\n\n- Use dependency injection for ALL services\n- Validate ALL inputs via DTOs with `class-validator`\n- Define repository interfaces in domain layer, implement in infrastructure\n- Prefix entities with module name (e.g., `BillingPlan`, not `Plan`)\n- Use events for cross-module communication\n- Document module public API via exports in NestJS module\n- Write unit tests for services or command\u002Fquery handlers\n- Use environment variables for ALL configuration\n- Document APIs with Swagger decorators (REST) or tRPC router types\n\n### MUST NOT DO\n\n- ❌ Share database tables across modules\n- ❌ Import internal services from another module directly\n- ❌ Use `any` type — leverage TypeScript strict mode\n- ❌ Create circular dependencies between modules\n- ❌ Use Node.js EventEmitter for production inter-module communication\n- ❌ Use generic entity names (`User`, `Plan`, `Item`) without module prefix\n- ❌ Hardcode configuration values\n- ❌ Skip error handling — use domain-specific exceptions\n- ❌ Export internal services that should stay private to a module\n- ❌ Access shared mutable state across modules\n- ❌ Force CQRS on modules that don't need it — start simple\n\n## Output Templates\n\nWhen implementing a complete module, provide files in this order:\n\n1. **Domain entities** — With module-prefixed names and business logic\n2. **Repository interface** — In domain layer, defines data access contract\n3. **Service** (default) or **Commands\u002FQueries + Handlers** (if CQRS) — Implementing business rules\n4. **DTOs** — Request\u002Fresponse with Swagger decorators and validation\n5. **Repository implementation** — Prisma\u002FTypeORM in infrastructure layer\n6. **Controller** — With guards, Swagger docs, and proper HTTP codes\n7. **Module definition** — NestJS module with explicit imports\u002Fexports\n8. **Tests** — Unit tests for services\u002Fhandlers, integration tests for boundaries\n9. **Domain events** — If cross-module communication is needed\n\nWhen designing architecture (not implementing), provide:\n\n1. **Executive Summary** — Architecture overview, key decisions, rationale\n2. **Bounded Contexts Map** — Responsibilities, aggregates, communication\n3. **Module Interface Contracts** — Public API surface of each module\n4. **Data Model** — Per-module schemas with ownership boundaries\n5. **Communication Diagram** — Event flows between modules\n6. **Evolution Path** — How to extract modules to microservices later\n\n## Quick Anti-Pattern Detection\n\nBefore finalizing any module, run `scripts\u002Fvalidate-isolation.sh` or verify manually:\n\n```bash\n# Check duplicate entity names across modules\ngrep -r \"@Entity.*name:\" libs\u002F | grep -o \"name: '[^']*'\" | sort | uniq -d\n\n# Detect direct cross-module imports (should only import from index)\ngrep -r \"from.*@company.*\u002F\" libs\u002F | grep -v shared | grep -v index\n\n# Find shared mutable state\ngrep -r \"export.*=.*new\" libs\u002F | grep -v test\n\n# Check for synchronous inter-module calls\ngrep -r \"await.*\\..*Service\" libs\u002F | grep -v \"this\\.\"\n```\n\nIf any check finds violations, fix them before proceeding.\n\n## MCP Tools\n\nUse these MCP tools when available for enhanced results:\n\n- **context7**: Query latest docs for NestJS, Prisma, Better Auth, NX, and other stack components. Always prefer fresh docs over built-in knowledge.\n- **sequential-thinking**: Use for complex architectural analysis, multi-step design decisions, and tradeoff evaluation.\n\n## Knowledge Reference\n\nNestJS, Fastify, Express, TypeScript, NX, Prisma, TypeORM, tRPC, DDD, Clean Architecture, CQRS, Event Sourcing, Bounded Contexts, Domain Events, Passport, JWT, Better Auth, class-validator, class-transformer, Swagger\u002FOpenAPI, Jest, Supertest, Biome, Kafka, SQS, Redis, RabbitMQ\n",{},"main","def8531e65114c0fca8fb8551c1871ee0eed705c","skills\u002Ftech-leads-club\u002Fagent-skills\u002Fnestjs-modular-monolith",24,"https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub","https:\u002F\u002Fskillshub.wtf","https:\u002F\u002Fgithub.com\u002FComeOnOliver","AI & Blockchain Engineer\r\n","2026-06-24 22:07:19",{"source":7,"skillName":5,"commands":40,"prompt":50,"zipAvailable":51},[41,44,47],{"tool":42,"command":43},"npx","npx skills add ComeOnOliver\u002Fskillshub --skill nestjs-modular-monolith",{"tool":45,"command":46},"bunx","bunx skills add ComeOnOliver\u002Fskillshub --skill nestjs-modular-monolith",{"tool":48,"command":49},"pnpm","pnpm dlx skills add ComeOnOliver\u002Fskillshub --skill nestjs-modular-monolith","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Ftech-leads-club\u002Fagent-skills\u002Fnestjs-modular-monolith\u002FSKILL.md",true,[],[54,64,74,83,89,96],{"skillNo":55,"name":56,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":57,"categories":58,"keywords":60,"publishedAt":26},"01M6FKJN13GMG4KY57J3QD8GY5","model-hierarchy-skill","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzscole\u002Fmodel-hierarchy-skill\u002Fmodel-hierarchy-skill\u002FSKILL.md",[59],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[61,62,63],"model","model hierarchy","model hierarchy skill",{"skillNo":65,"name":66,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":70,"publishedAt":26},"01M6FKJJJ6GCAMR4PPPRD12M5X","zoom-mcp","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fzoom-mcp\u002FSKILL.md",[69],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[71,72,73],"MCP","zoom","zoom mcp",{"skillNo":75,"name":76,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":26},"01M6FKJE3KYT3KPEZMEEHYKA6K","zoom-apps-sdk","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fzoom-apps-sdk\u002FSKILL.md",[],[80,81,82,72],"sdk","zoom apps sdk","apps",{"skillNo":84,"name":85,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":26},"01M6FKJ9EDH9Q5VWDF8HAJRSP0","windows","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwindows\u002FSKILL.md",[],[85],{"skillNo":90,"name":91,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":95,"publishedAt":26},"01M6FKJ666BEEFC3AE9GJ72Q93","whiteboard","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwhiteboard\u002FSKILL.md",[94],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[91],{"skillNo":97,"name":98,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":7,"ownerLogin":8,"ownerAvatarUrl":9,"ownerAccountNo":10,"ownerDisplayName":11,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":26},"01M6FKJ21WFCDGTJQ2Q91T9DVW","websockets","https:\u002F\u002Fgithub.com\u002FComeOnOliver\u002Fskillshub\u002Fblob\u002Fmain\u002Fskills\u002Fzoom\u002Fskills\u002Fwebsockets\u002FSKILL.md",[],[98]]