{"id":"b5c372f3-3bbe-4cb3-8d92-ca55cbd68748","entityType":"agent","slug":"clawhub-athola-nm-archetypes-architecture-paradigm-modular-mono","name":"architecture-paradigm-modular-monolith","canonicalUrl":"https://www.xpersona.co/agent/clawhub-athola-nm-archetypes-architecture-paradigm-modular-mono","canonicalPath":"/agent/clawhub-athola-nm-archetypes-architecture-paradigm-modular-mono","generatedAt":"2026-10-10T04:36:22.864Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-10T02:44:55.910Z","emptyReason":null},"description":"Applies modular monolith with enforced internal boundaries Skill: architecture-paradigm-modular-monolith Owner: athola Summary: Applies modular monolith with enforced internal boundaries Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:05:41.761Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:29:33.027Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:29:20.464Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:46:27.682Z | user Release v1.9.16 v1.9.15 | 2026-07-04T21","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.8K downloads reported by the source. Last updated 10/10/2026.","installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-archetypes-architecture-paradigm-modular-monolith","sourceUrl":"https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-modular-monolith","homepage":"https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-modular-monolith","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-modular-monolith","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-modular-monolith","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":40,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Applies modular monolith with enforced internal boundaries Skill: architecture-paradigm-modular-monolith Owner: athola Summary: Applies modular monolith with en"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T02:44:55.910Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T02:44:55.910Z","emptyReason":null},"stars":null,"forks":null,"downloads":1761,"packageName":null,"latestVersion":"1.9.19","tractionLabel":"1.8K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T02:44:55.909Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T02:44:55.910Z","lastCrawledAt":"2026-10-10T02:44:55.909Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T02:44:55.909Z","lastVerifiedAt":null,"highlights":[{"version":"1.9.19","createdAt":"2026-08-26T13:05:41.761Z","changelog":"Release v1.9.19","fileCount":3,"zipByteSize":3475},{"version":"1.9.18","createdAt":"2026-08-15T21:29:33.027Z","changelog":"Release v1.9.18","fileCount":3,"zipByteSize":3497},{"version":"1.9.17","createdAt":"2026-07-30T05:29:20.464Z","changelog":"Release v1.9.17","fileCount":3,"zipByteSize":3644},{"version":"1.9.16","createdAt":"2026-07-14T19:46:27.682Z","changelog":"Release v1.9.16","fileCount":3,"zipByteSize":3489},{"version":"1.9.15","createdAt":"2026-07-04T21:20:29.462Z","changelog":"Release v1.9.15","fileCount":3,"zipByteSize":3520},{"version":"1.9.14","createdAt":"2026-06-30T17:51:06.421Z","changelog":"Release v1.9.14","fileCount":3,"zipByteSize":3552},{"version":"1.9.13","createdAt":"2026-06-27T16:15:33.808Z","changelog":"Release v1.9.13","fileCount":3,"zipByteSize":3565},{"version":"1.9.12","createdAt":"2026-06-19T03:08:56.184Z","changelog":"Release v1.9.12","fileCount":3,"zipByteSize":3643}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-archetypes-architecture-paradigm-modular-monolith","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-modular-mono/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-modular-mono/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-modular-mono/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-modular-mono/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-modular-mono/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-modular-mono/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T04:36:22.863Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-modular-mono/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-modular-mono/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-modular-mono/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-modular-mono/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-10T02:44:55.910Z","emptyReason":null},"readme":"Skill: architecture-paradigm-modular-monolith\n\nOwner: athola\n\nSummary: Applies modular monolith with enforced internal boundaries\n\nTags: latest:1.9.19\n\nVersion history:\n\nv1.9.19 | 2026-08-26T13:05:41.761Z | user\n\nRelease v1.9.19\n\nv1.9.18 | 2026-08-15T21:29:33.027Z | user\n\nRelease v1.9.18\n\nv1.9.17 | 2026-07-30T05:29:20.464Z | user\n\nRelease v1.9.17\n\nv1.9.16 | 2026-07-14T19:46:27.682Z | user\n\nRelease v1.9.16\n\nv1.9.15 | 2026-07-04T21:20:29.462Z | user\n\nRelease v1.9.15\n\nv1.9.14 | 2026-06-30T17:51:06.421Z | user\n\nRelease v1.9.14\n\nv1.9.13 | 2026-06-27T16:15:33.808Z | user\n\nRelease v1.9.13\n\nv1.9.12 | 2026-06-19T03:08:56.184Z | user\n\nRelease v1.9.12\n\nv1.8.6 | 2026-06-07T21:22:53.163Z | user\n\nRelease v1.9.11\n\nv1.8.5 | 2026-05-09T02:15:30.591Z | user\n\nRelease v1.9.5\n\nv1.8.4 | 2026-05-06T14:15:15.991Z | user\n\nRelease v1.9.4\n\nv1.8.3 | 2026-04-10T05:45:47.987Z | user\n\nRelease v1.8.3\n\nArchive index:\n\nArchive v1.9.19: 3 files, 3475 bytes\n\nFiles: skill-card.md (1946b), SKILL.md (4094b), _meta.json (172b)\n\nFile v1.9.19:SKILL.md\n\n---\nname: architecture-paradigm-modular-monolith\ndescription: Applies modular monolith with enforced internal boundaries\nversion: 1.9.8\ntriggers:\n  - architecture\n  - modular-monolith\n  - monolith\n  - internal-boundaries\n  - team-autonomy\n  - teams want service-level autonomy without distributed system overhead\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Modular Monolith Paradigm\n\n\n## When To Use\n\n- Organizing large codebases into well-bounded modules\n- Teams wanting microservice boundaries without distributed complexity\n\n## When NOT To Use\n\n- Already distributed as microservices\n- Tiny applications where module boundaries add unnecessary complexity\n\n## When to Employ This Paradigm\n- When you desire team autonomy similar to that of microservices, but without the operational overhead of a distributed system.\n- When release velocity is slowed by tangled dependencies between internal modules.\n- When a monolithic architecture is simpler to operate today, but there is a clear need to evolve toward a service-based model in the future.\n\n## Adoption Steps\n1. **Identify Modules**: Define module boundaries that align with distinct business capabilities or Bounded Contexts from Domain-Driven Design.\n2. **Encapsulate Internals**: Use language-level visibility modifiers (e.g., public/private), separate packages, or namespaces to hide the implementation details of each module.\n3. **Expose Public Contracts**: Each module should expose its functionality through well-defined facades, APIs, or events. Forbid direct database table access or direct implementation calls between modules.\n4. **Enforce Architectural Fitness**: Implement automated tests that fail the build if forbidden dependencies or package references are introduced between modules.\n5. **Plan for Evolution**: Continuously track metrics such as change coupling and deployment scope to make informed decisions about if and when to split a module into a separate service.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that maps module boundaries and defines the rules for any shared code.\n- Formal contract documentation (e.g., OpenAPI specs, event schemas) for every interaction point between modules.\n- Automated dependency checks and dedicated CI/CD jobs for each module to enforce boundaries.\n\n## Risks & Mitigations\n- **Regression to a \"Big Ball of Mud\"**:\n  - **Mitigation**: Without strict enforcement, module boundaries will inevitably erode. Treat any boundary violation as a build-breaking error and maintain a disciplined approach to code reviews.\n- **Shared Database Hotspots**:\n  - **Mitigation**: High contention on a shared database can become a bottleneck. Introduce clear schema ownership, use view-based access to restrict data visibility, or implement data replication strategies to reduce coupling.\n## Troubleshooting\n\n### Common Issues\n\n**Skill not loading**\nCheck YAML frontmatter syntax and required fields\n\n**Token limits exceeded**\nUse progressive disclosure - move details to modules\n\n**Modules not found**\nVerify module paths in SKILL.md are correct\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``dependency-analyzer`` -- module dependency graph builder for spotting forbidden edges\n- ``module-boundary-enforcer`` -- fails the build when a module imports across a boundary\n- ``refactoring-planner`` -- ranks modules by extraction-readiness for a future split\n\nFile v1.9.19:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-modular-monolith\",\n  \"version\": \"1.9.19\",\n  \"publishedAt\": 1787749541761\n}\n\nFile v1.9.19:skill-card.md\n\n## Description:\n\nApplies modular monolith with enforced internal boundaries.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[athola](https://clawhub.ai/user/athola)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and architecture teams use this skill to organize large codebases into well-bounded modules, preserve monolith operational simplicity, and enforce internal boundaries as systems grow.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Broad architecture triggers may activate the skill during general architecture conversations.\n\nMitigation: Use specific invocation language for modular monolith work, or narrow triggers when a workspace needs more selective activation.\n\nRisk: Architecture recommendations may be misapplied if module boundaries are not reviewed and enforced.\n\nMitigation: Review proposed boundaries with the engineering team and back them with dependency checks, contract documentation, and CI enforcement.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-modular-monolith)\n- [OpenClaw homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes)\n\n## Skill Output:\n\n**Output Type(s):** [Guidance, Markdown, Configuration]\n\n**Output Format:** [Markdown guidance with checklists and architecture recommendations]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [No code execution; may suggest ADRs, contract documentation, dependency checks, and CI boundary enforcement.]\n\n## Skill Version(s):\n\n1.9.19 (source: server release metadata; artifact frontmatter lists 1.9.8)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.9.18: 3 files, 3497 bytes\n\nFiles: skill-card.md (1955b), SKILL.md (4094b), _meta.json (172b)\n\nFile v1.9.18:SKILL.md\n\n---\nname: architecture-paradigm-modular-monolith\ndescription: Applies modular monolith with enforced internal boundaries\nversion: 1.9.8\ntriggers:\n  - architecture\n  - modular-monolith\n  - monolith\n  - internal-boundaries\n  - team-autonomy\n  - teams want service-level autonomy without distributed system overhead\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Modular Monolith Paradigm\n\n\n## When To Use\n\n- Organizing large codebases into well-bounded modules\n- Teams wanting microservice boundaries without distributed complexity\n\n## When NOT To Use\n\n- Already distributed as microservices\n- Tiny applications where module boundaries add unnecessary complexity\n\n## When to Employ This Paradigm\n- When you desire team autonomy similar to that of microservices, but without the operational overhead of a distributed system.\n- When release velocity is slowed by tangled dependencies between internal modules.\n- When a monolithic architecture is simpler to operate today, but there is a clear need to evolve toward a service-based model in the future.\n\n## Adoption Steps\n1. **Identify Modules**: Define module boundaries that align with distinct business capabilities or Bounded Contexts from Domain-Driven Design.\n2. **Encapsulate Internals**: Use language-level visibility modifiers (e.g., public/private), separate packages, or namespaces to hide the implementation details of each module.\n3. **Expose Public Contracts**: Each module should expose its functionality through well-defined facades, APIs, or events. Forbid direct database table access or direct implementation calls between modules.\n4. **Enforce Architectural Fitness**: Implement automated tests that fail the build if forbidden dependencies or package references are introduced between modules.\n5. **Plan for Evolution**: Continuously track metrics such as change coupling and deployment scope to make informed decisions about if and when to split a module into a separate service.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that maps module boundaries and defines the rules for any shared code.\n- Formal contract documentation (e.g., OpenAPI specs, event schemas) for every interaction point between modules.\n- Automated dependency checks and dedicated CI/CD jobs for each module to enforce boundaries.\n\n## Risks & Mitigations\n- **Regression to a \"Big Ball of Mud\"**:\n  - **Mitigation**: Without strict enforcement, module boundaries will inevitably erode. Treat any boundary violation as a build-breaking error and maintain a disciplined approach to code reviews.\n- **Shared Database Hotspots**:\n  - **Mitigation**: High contention on a shared database can become a bottleneck. Introduce clear schema ownership, use view-based access to restrict data visibility, or implement data replication strategies to reduce coupling.\n## Troubleshooting\n\n### Common Issues\n\n**Skill not loading**\nCheck YAML frontmatter syntax and required fields\n\n**Token limits exceeded**\nUse progressive disclosure - move details to modules\n\n**Modules not found**\nVerify module paths in SKILL.md are correct\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``dependency-analyzer`` -- module dependency graph builder for spotting forbidden edges\n- ``module-boundary-enforcer`` -- fails the build when a module imports across a boundary\n- ``refactoring-planner`` -- ranks modules by extraction-readiness for a future split\n\nFile v1.9.18:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-modular-monolith\",\n  \"version\": \"1.9.18\",\n  \"publishedAt\": 1786829373027\n}\n\nFile v1.9.18:skill-card.md\n\n## Description:\n\nApplies modular monolith with enforced internal boundaries.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[athola](https://clawhub.ai/user/athola)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and architects use this skill to evaluate when a modular monolith is appropriate and to plan module boundaries, public contracts, dependency checks, and future service extraction paths.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Broad architecture triggers may activate the skill in discussions where modular monolith guidance is not the best fit.\n\nMitigation: Confirm the system is a monolith or a candidate for consolidated modular boundaries before applying the recommendations.\n\nRisk: Architecture advice can be misleading if accepted without reviewing local team structure, coupling, and operational constraints.\n\nMitigation: Review recommendations with project owners and validate boundary rules through dependency checks before treating them as implementation policy.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-modular-monolith)\n- [OpenClaw homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes)\n\n## Skill Output:\n\n**Output Type(s):** [Guidance, Markdown]\n\n**Output Format:** [Markdown prose with architecture recommendations, adoption steps, deliverables, and risk notes]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Advisory content only; no tools, credentials, or external actions are requested.]\n\n## Skill Version(s):\n\n1.9.18 (source: server release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.9.17: 3 files, 3644 bytes\n\nFiles: skill-card.md (2390b), SKILL.md (4094b), _meta.json (172b)\n\nFile v1.9.17:SKILL.md\n\n---\nname: architecture-paradigm-modular-monolith\ndescription: Applies modular monolith with enforced internal boundaries\nversion: 1.9.8\ntriggers:\n  - architecture\n  - modular-monolith\n  - monolith\n  - internal-boundaries\n  - team-autonomy\n  - teams want service-level autonomy without distributed system overhead\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Modular Monolith Paradigm\n\n\n## When To Use\n\n- Organizing large codebases into well-bounded modules\n- Teams wanting microservice boundaries without distributed complexity\n\n## When NOT To Use\n\n- Already distributed as microservices\n- Tiny applications where module boundaries add unnecessary complexity\n\n## When to Employ This Paradigm\n- When you desire team autonomy similar to that of microservices, but without the operational overhead of a distributed system.\n- When release velocity is slowed by tangled dependencies between internal modules.\n- When a monolithic architecture is simpler to operate today, but there is a clear need to evolve toward a service-based model in the future.\n\n## Adoption Steps\n1. **Identify Modules**: Define module boundaries that align with distinct business capabilities or Bounded Contexts from Domain-Driven Design.\n2. **Encapsulate Internals**: Use language-level visibility modifiers (e.g., public/private), separate packages, or namespaces to hide the implementation details of each module.\n3. **Expose Public Contracts**: Each module should expose its functionality through well-defined facades, APIs, or events. Forbid direct database table access or direct implementation calls between modules.\n4. **Enforce Architectural Fitness**: Implement automated tests that fail the build if forbidden dependencies or package references are introduced between modules.\n5. **Plan for Evolution**: Continuously track metrics such as change coupling and deployment scope to make informed decisions about if and when to split a module into a separate service.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that maps module boundaries and defines the rules for any shared code.\n- Formal contract documentation (e.g., OpenAPI specs, event schemas) for every interaction point between modules.\n- Automated dependency checks and dedicated CI/CD jobs for each module to enforce boundaries.\n\n## Risks & Mitigations\n- **Regression to a \"Big Ball of Mud\"**:\n  - **Mitigation**: Without strict enforcement, module boundaries will inevitably erode. Treat any boundary violation as a build-breaking error and maintain a disciplined approach to code reviews.\n- **Shared Database Hotspots**:\n  - **Mitigation**: High contention on a shared database can become a bottleneck. Introduce clear schema ownership, use view-based access to restrict data visibility, or implement data replication strategies to reduce coupling.\n## Troubleshooting\n\n### Common Issues\n\n**Skill not loading**\nCheck YAML frontmatter syntax and required fields\n\n**Token limits exceeded**\nUse progressive disclosure - move details to modules\n\n**Modules not found**\nVerify module paths in SKILL.md are correct\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``dependency-analyzer`` -- module dependency graph builder for spotting forbidden edges\n- ``module-boundary-enforcer`` -- fails the build when a module imports across a boundary\n- ``refactoring-planner`` -- ranks modules by extraction-readiness for a future split\n\nFile v1.9.17:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-modular-monolith\",\n  \"version\": \"1.9.17\",\n  \"publishedAt\": 1785389360464\n}\n\nFile v1.9.17:skill-card.md\n\n## Description: <br>\nApplies modular monolith guidance with enforced internal boundaries. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and software architecture teams use this skill to decide when a modular monolith is appropriate and to plan internal module boundaries, contracts, dependency checks, and evolution paths. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Broad trigger terms such as \"architecture\" and \"monolith\" may activate the skill in unrelated design discussions. <br>\nMitigation: Use narrower activation terms or confirm that modular monolith guidance is relevant before applying the skill output. <br>\nRisk: Architecture guidance can be misapplied to systems that are already distributed or too small to benefit from formal module boundaries. <br>\nMitigation: Check the system context before adopting the pattern and avoid using the guidance where the artifact's stated non-use cases apply. <br>\nRisk: Module boundaries may erode over time if teams do not enforce dependency rules. <br>\nMitigation: Pair the guidance with code review discipline and automated dependency checks that fail when forbidden module references are introduced. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-modular-monolith) <br>\n- [OpenClaw metadata homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [guidance, markdown] <br>\n**Output Format:** [Markdown guidance with architecture recommendations, adoption steps, deliverables, troubleshooting notes, and risk mitigations.] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Documentation-only skill; no executable tools, credential use, or API calls are indicated by the evidence.] <br>\n\n## Skill Version(s): <br>\n1.9.17 (source: server release metadata) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.16: 3 files, 3489 bytes\n\nFiles: skill-card.md (2062b), SKILL.md (4094b), _meta.json (172b)\n\nFile v1.9.16:SKILL.md\n\n---\nname: architecture-paradigm-modular-monolith\ndescription: Applies modular monolith with enforced internal boundaries\nversion: 1.9.8\ntriggers:\n  - architecture\n  - modular-monolith\n  - monolith\n  - internal-boundaries\n  - team-autonomy\n  - teams want service-level autonomy without distributed system overhead\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Modular Monolith Paradigm\n\n\n## When To Use\n\n- Organizing large codebases into well-bounded modules\n- Teams wanting microservice boundaries without distributed complexity\n\n## When NOT To Use\n\n- Already distributed as microservices\n- Tiny applications where module boundaries add unnecessary complexity\n\n## When to Employ This Paradigm\n- When you desire team autonomy similar to that of microservices, but without the operational overhead of a distributed system.\n- When release velocity is slowed by tangled dependencies between internal modules.\n- When a monolithic architecture is simpler to operate today, but there is a clear need to evolve toward a service-based model in the future.\n\n## Adoption Steps\n1. **Identify Modules**: Define module boundaries that align with distinct business capabilities or Bounded Contexts from Domain-Driven Design.\n2. **Encapsulate Internals**: Use language-level visibility modifiers (e.g., public/private), separate packages, or namespaces to hide the implementation details of each module.\n3. **Expose Public Contracts**: Each module should expose its functionality through well-defined facades, APIs, or events. Forbid direct database table access or direct implementation calls between modules.\n4. **Enforce Architectural Fitness**: Implement automated tests that fail the build if forbidden dependencies or package references are introduced between modules.\n5. **Plan for Evolution**: Continuously track metrics such as change coupling and deployment scope to make informed decisions about if and when to split a module into a separate service.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that maps module boundaries and defines the rules for any shared code.\n- Formal contract documentation (e.g., OpenAPI specs, event schemas) for every interaction point between modules.\n- Automated dependency checks and dedicated CI/CD jobs for each module to enforce boundaries.\n\n## Risks & Mitigations\n- **Regression to a \"Big Ball of Mud\"**:\n  - **Mitigation**: Without strict enforcement, module boundaries will inevitably erode. Treat any boundary violation as a build-breaking error and maintain a disciplined approach to code reviews.\n- **Shared Database Hotspots**:\n  - **Mitigation**: High contention on a shared database can become a bottleneck. Introduce clear schema ownership, use view-based access to restrict data visibility, or implement data replication strategies to reduce coupling.\n## Troubleshooting\n\n### Common Issues\n\n**Skill not loading**\nCheck YAML frontmatter syntax and required fields\n\n**Token limits exceeded**\nUse progressive disclosure - move details to modules\n\n**Modules not found**\nVerify module paths in SKILL.md are correct\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``dependency-analyzer`` -- module dependency graph builder for spotting forbidden edges\n- ``module-boundary-enforcer`` -- fails the build when a module imports across a boundary\n- ``refactoring-planner`` -- ranks modules by extraction-readiness for a future split\n\nFile v1.9.16:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-modular-monolith\",\n  \"version\": \"1.9.16\",\n  \"publishedAt\": 1784058387682\n}\n\nFile v1.9.16:skill-card.md\n\n## Description: <br>\nApplies modular monolith guidance with enforced internal boundaries. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and architecture teams use this skill to decide when a modular monolith fits a codebase and to plan module boundaries, public contracts, and enforcement checks. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may appear during broad architecture prompts even when a modular monolith is not the right fit. <br>\nMitigation: Confirm the application needs bounded modules and service-like autonomy without distributed-system overhead before applying the guidance. <br>\nRisk: Architecture recommendations can become misleading if module boundaries and contracts are not enforced. <br>\nMitigation: Review proposed boundaries with project owners and back them with dependency checks, contract documentation, or CI enforcement before relying on the pattern. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-modular-monolith) <br>\n- [Claude Night Market archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Guidance, Markdown] <br>\n**Output Format:** [Markdown guidance with bullet lists and architecture recommendations] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Documentation-only; no tools, secrets, code execution, data access, or persistence are required.] <br>\n\n## Skill Version(s): <br>\n1.9.16 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.15: 3 files, 3520 bytes\n\nFiles: skill-card.md (2148b), SKILL.md (4094b), _meta.json (172b)\n\nFile v1.9.15:SKILL.md\n\n---\nname: architecture-paradigm-modular-monolith\ndescription: Applies modular monolith with enforced internal boundaries\nversion: 1.9.8\ntriggers:\n  - architecture\n  - modular-monolith\n  - monolith\n  - internal-boundaries\n  - team-autonomy\n  - teams want service-level autonomy without distributed system overhead\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Modular Monolith Paradigm\n\n\n## When To Use\n\n- Organizing large codebases into well-bounded modules\n- Teams wanting microservice boundaries without distributed complexity\n\n## When NOT To Use\n\n- Already distributed as microservices\n- Tiny applications where module boundaries add unnecessary complexity\n\n## When to Employ This Paradigm\n- When you desire team autonomy similar to that of microservices, but without the operational overhead of a distributed system.\n- When release velocity is slowed by tangled dependencies between internal modules.\n- When a monolithic architecture is simpler to operate today, but there is a clear need to evolve toward a service-based model in the future.\n\n## Adoption Steps\n1. **Identify Modules**: Define module boundaries that align with distinct business capabilities or Bounded Contexts from Domain-Driven Design.\n2. **Encapsulate Internals**: Use language-level visibility modifiers (e.g., public/private), separate packages, or namespaces to hide the implementation details of each module.\n3. **Expose Public Contracts**: Each module should expose its functionality through well-defined facades, APIs, or events. Forbid direct database table access or direct implementation calls between modules.\n4. **Enforce Architectural Fitness**: Implement automated tests that fail the build if forbidden dependencies or package references are introduced between modules.\n5. **Plan for Evolution**: Continuously track metrics such as change coupling and deployment scope to make informed decisions about if and when to split a module into a separate service.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that maps module boundaries and defines the rules for any shared code.\n- Formal contract documentation (e.g., OpenAPI specs, event schemas) for every interaction point between modules.\n- Automated dependency checks and dedicated CI/CD jobs for each module to enforce boundaries.\n\n## Risks & Mitigations\n- **Regression to a \"Big Ball of Mud\"**:\n  - **Mitigation**: Without strict enforcement, module boundaries will inevitably erode. Treat any boundary violation as a build-breaking error and maintain a disciplined approach to code reviews.\n- **Shared Database Hotspots**:\n  - **Mitigation**: High contention on a shared database can become a bottleneck. Introduce clear schema ownership, use view-based access to restrict data visibility, or implement data replication strategies to reduce coupling.\n## Troubleshooting\n\n### Common Issues\n\n**Skill not loading**\nCheck YAML frontmatter syntax and required fields\n\n**Token limits exceeded**\nUse progressive disclosure - move details to modules\n\n**Modules not found**\nVerify module paths in SKILL.md are correct\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``dependency-analyzer`` -- module dependency graph builder for spotting forbidden edges\n- ``module-boundary-enforcer`` -- fails the build when a module imports across a boundary\n- ``refactoring-planner`` -- ranks modules by extraction-readiness for a future split\n\nFile v1.9.15:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-modular-monolith\",\n  \"version\": \"1.9.15\",\n  \"publishedAt\": 1783200029462\n}\n\nFile v1.9.15:skill-card.md\n\n## Description: <br>\nApplies modular monolith guidance with enforced internal boundaries. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and architecture teams use this skill to plan modular monoliths with well-bounded modules, internal contracts, and automated boundary checks. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may appear on broad architecture-related prompts. <br>\nMitigation: Disable or narrow the skill when modular monolith guidance should only appear for explicit requests. <br>\nRisk: Architecture guidance could be incorrect or incomplete for a specific codebase. <br>\nMitigation: Review recommendations before adoption and validate module boundaries with dependency checks and code review. <br>\nRisk: Shared database coupling can undermine modular boundaries. <br>\nMitigation: Use clear schema ownership, restricted data access patterns, and boundary enforcement before relying on the architecture. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-modular-monolith) <br>\n- [Project homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Guidance, Markdown, Configuration] <br>\n**Output Format:** [Markdown guidance with architecture recommendations and deliverable outlines] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [No executable code; produces architecture guidance for modular monolith boundaries and adoption steps.] <br>\n\n## Skill Version(s): <br>\n1.9.15 (source: server release metadata; artifact frontmatter reports 1.9.8) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.14: 3 files, 3552 bytes\n\nFiles: skill-card.md (2081b), SKILL.md (4094b), _meta.json (172b)\n\nFile v1.9.14:SKILL.md\n\n---\nname: architecture-paradigm-modular-monolith\ndescription: Applies modular monolith with enforced internal boundaries\nversion: 1.9.8\ntriggers:\n  - architecture\n  - modular-monolith\n  - monolith\n  - internal-boundaries\n  - team-autonomy\n  - teams want service-level autonomy without distributed system overhead\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Modular Monolith Paradigm\n\n\n## When To Use\n\n- Organizing large codebases into well-bounded modules\n- Teams wanting microservice boundaries without distributed complexity\n\n## When NOT To Use\n\n- Already distributed as microservices\n- Tiny applications where module boundaries add unnecessary complexity\n\n## When to Employ This Paradigm\n- When you desire team autonomy similar to that of microservices, but without the operational overhead of a distributed system.\n- When release velocity is slowed by tangled dependencies between internal modules.\n- When a monolithic architecture is simpler to operate today, but there is a clear need to evolve toward a service-based model in the future.\n\n## Adoption Steps\n1. **Identify Modules**: Define module boundaries that align with distinct business capabilities or Bounded Contexts from Domain-Driven Design.\n2. **Encapsulate Internals**: Use language-level visibility modifiers (e.g., public/private), separate packages, or namespaces to hide the implementation details of each module.\n3. **Expose Public Contracts**: Each module should expose its functionality through well-defined facades, APIs, or events. Forbid direct database table access or direct implementation calls between modules.\n4. **Enforce Architectural Fitness**: Implement automated tests that fail the build if forbidden dependencies or package references are introduced between modules.\n5. **Plan for Evolution**: Continuously track metrics such as change coupling and deployment scope to make informed decisions about if and when to split a module into a separate service.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that maps module boundaries and defines the rules for any shared code.\n- Formal contract documentation (e.g., OpenAPI specs, event schemas) for every interaction point between modules.\n- Automated dependency checks and dedicated CI/CD jobs for each module to enforce boundaries.\n\n## Risks & Mitigations\n- **Regression to a \"Big Ball of Mud\"**:\n  - **Mitigation**: Without strict enforcement, module boundaries will inevitably erode. Treat any boundary violation as a build-breaking error and maintain a disciplined approach to code reviews.\n- **Shared Database Hotspots**:\n  - **Mitigation**: High contention on a shared database can become a bottleneck. Introduce clear schema ownership, use view-based access to restrict data visibility, or implement data replication strategies to reduce coupling.\n## Troubleshooting\n\n### Common Issues\n\n**Skill not loading**\nCheck YAML frontmatter syntax and required fields\n\n**Token limits exceeded**\nUse progressive disclosure - move details to modules\n\n**Modules not found**\nVerify module paths in SKILL.md are correct\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``dependency-analyzer`` -- module dependency graph builder for spotting forbidden edges\n- ``module-boundary-enforcer`` -- fails the build when a module imports across a boundary\n- ``refactoring-planner`` -- ranks modules by extraction-readiness for a future split\n\nFile v1.9.14:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-modular-monolith\",\n  \"version\": \"1.9.14\",\n  \"publishedAt\": 1782841866421\n}\n\nFile v1.9.14:skill-card.md\n\n## Description: <br>\nApplies modular monolith with enforced internal boundaries. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and software architects use this skill to structure large monoliths into well-bounded modules with clear internal contracts, dependency checks, and a path toward future service extraction. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The artifact mentions a separate Claude Code plugin that can include agents, hooks, and commands outside the reviewed skill artifact. <br>\nMitigation: Review and scan any separate plugin before installing or enabling it. <br>\nRisk: Architecture guidance may be applied too broadly to tiny applications or systems that are already distributed as microservices. <br>\nMitigation: Use the skill's stated fit criteria before adopting modular monolith practices. <br>\n\n\n## Reference(s): <br>\n- [ClawHub Skill Page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-modular-monolith) <br>\n- [OpenClaw Homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Guidance, Markdown, Configuration, Code] <br>\n**Output Format:** [Markdown guidance with architecture recommendations, deliverables, and implementation-oriented checks] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Documentation-only artifact; no executable behavior or credential requests were identified in the security evidence.] <br>\n\n## Skill Version(s): <br>\n1.9.14 (source: server release metadata; artifact frontmatter says 1.9.8) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.13: 3 files, 3565 bytes\n\nFiles: skill-card.md (2147b), SKILL.md (4094b), _meta.json (172b)\n\nFile v1.9.13:SKILL.md\n\n---\nname: architecture-paradigm-modular-monolith\ndescription: Applies modular monolith with enforced internal boundaries\nversion: 1.9.8\ntriggers:\n  - architecture\n  - modular-monolith\n  - monolith\n  - internal-boundaries\n  - team-autonomy\n  - teams want service-level autonomy without distributed system overhead\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Modular Monolith Paradigm\n\n\n## When To Use\n\n- Organizing large codebases into well-bounded modules\n- Teams wanting microservice boundaries without distributed complexity\n\n## When NOT To Use\n\n- Already distributed as microservices\n- Tiny applications where module boundaries add unnecessary complexity\n\n## When to Employ This Paradigm\n- When you desire team autonomy similar to that of microservices, but without the operational overhead of a distributed system.\n- When release velocity is slowed by tangled dependencies between internal modules.\n- When a monolithic architecture is simpler to operate today, but there is a clear need to evolve toward a service-based model in the future.\n\n## Adoption Steps\n1. **Identify Modules**: Define module boundaries that align with distinct business capabilities or Bounded Contexts from Domain-Driven Design.\n2. **Encapsulate Internals**: Use language-level visibility modifiers (e.g., public/private), separate packages, or namespaces to hide the implementation details of each module.\n3. **Expose Public Contracts**: Each module should expose its functionality through well-defined facades, APIs, or events. Forbid direct database table access or direct implementation calls between modules.\n4. **Enforce Architectural Fitness**: Implement automated tests that fail the build if forbidden dependencies or package references are introduced between modules.\n5. **Plan for Evolution**: Continuously track metrics such as change coupling and deployment scope to make informed decisions about if and when to split a module into a separate service.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that maps module boundaries and defines the rules for any shared code.\n- Formal contract documentation (e.g., OpenAPI specs, event schemas) for every interaction point between modules.\n- Automated dependency checks and dedicated CI/CD jobs for each module to enforce boundaries.\n\n## Risks & Mitigations\n- **Regression to a \"Big Ball of Mud\"**:\n  - **Mitigation**: Without strict enforcement, module boundaries will inevitably erode. Treat any boundary violation as a build-breaking error and maintain a disciplined approach to code reviews.\n- **Shared Database Hotspots**:\n  - **Mitigation**: High contention on a shared database can become a bottleneck. Introduce clear schema ownership, use view-based access to restrict data visibility, or implement data replication strategies to reduce coupling.\n## Troubleshooting\n\n### Common Issues\n\n**Skill not loading**\nCheck YAML frontmatter syntax and required fields\n\n**Token limits exceeded**\nUse progressive disclosure - move details to modules\n\n**Modules not found**\nVerify module paths in SKILL.md are correct\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``dependency-analyzer`` -- module dependency graph builder for spotting forbidden edges\n- ``module-boundary-enforcer`` -- fails the build when a module imports across a boundary\n- ``refactoring-planner`` -- ranks modules by extraction-readiness for a future split\n\nFile v1.9.13:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-modular-monolith\",\n  \"version\": \"1.9.13\",\n  \"publishedAt\": 1782576933808\n}\n\nFile v1.9.13:skill-card.md\n\n## Description: <br>\nApplies modular monolith with enforced internal boundaries. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and architects use this skill to plan modular monolith boundaries, public contracts, and enforcement checks for large codebases that need team autonomy without distributed-system overhead. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Architecture guidance may not match a project's domain boundaries or current operational constraints. <br>\nMitigation: Review the skill guidance against the target codebase and have architecture owners confirm module boundaries before adoption. <br>\nRisk: Weak enforcement can allow modular monolith boundaries to erode over time. <br>\nMitigation: Use automated dependency checks and CI jobs to fail builds when forbidden module dependencies are introduced. <br>\nRisk: Shared database ownership can create coupling and performance hotspots. <br>\nMitigation: Define schema ownership and restrict cross-module data access through documented contracts or controlled views. <br>\n\n\n## Reference(s): <br>\n- [claude-night-market archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [guidance, markdown, configuration] <br>\n**Output Format:** [Markdown guidance with structured architecture steps, deliverables, and troubleshooting notes] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Documentation-only skill; no tool calls, credentials, or hidden execution were identified in server security evidence.] <br>\n\n## Skill Version(s): <br>\n1.9.13 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.12: 3 files, 3643 bytes\n\nFiles: skill-card.md (2411b), SKILL.md (4094b), _meta.json (172b)\n\nFile v1.9.12:SKILL.md\n\n---\nname: architecture-paradigm-modular-monolith\ndescription: Applies modular monolith with enforced internal boundaries\nversion: 1.9.8\ntriggers:\n  - architecture\n  - modular-monolith\n  - monolith\n  - internal-boundaries\n  - team-autonomy\n  - teams want service-level autonomy without distributed system overhead\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Modular Monolith Paradigm\n\n\n## When To Use\n\n- Organizing large codebases into well-bounded modules\n- Teams wanting microservice boundaries without distributed complexity\n\n## When NOT To Use\n\n- Already distributed as microservices\n- Tiny applications where module boundaries add unnecessary complexity\n\n## When to Employ This Paradigm\n- When you desire team autonomy similar to that of microservices, but without the operational overhead of a distributed system.\n- When release velocity is slowed by tangled dependencies between internal modules.\n- When a monolithic architecture is simpler to operate today, but there is a clear need to evolve toward a service-based model in the future.\n\n## Adoption Steps\n1. **Identify Modules**: Define module boundaries that align with distinct business capabilities or Bounded Contexts from Domain-Driven Design.\n2. **Encapsulate Internals**: Use language-level visibility modifiers (e.g., public/private), separate packages, or namespaces to hide the implementation details of each module.\n3. **Expose Public Contracts**: Each module should expose its functionality through well-defined facades, APIs, or events. Forbid direct database table access or direct implementation calls between modules.\n4. **Enforce Architectural Fitness**: Implement automated tests that fail the build if forbidden dependencies or package references are introduced between modules.\n5. **Plan for Evolution**: Continuously track metrics such as change coupling and deployment scope to make informed decisions about if and when to split a module into a separate service.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that maps module boundaries and defines the rules for any shared code.\n- Formal contract documentation (e.g., OpenAPI specs, event schemas) for every interaction point between modules.\n- Automated dependency checks and dedicated CI/CD jobs for each module to enforce boundaries.\n\n## Risks & Mitigations\n- **Regression to a \"Big Ball of Mud\"**:\n  - **Mitigation**: Without strict enforcement, module boundaries will inevitably erode. Treat any boundary violation as a build-breaking error and maintain a disciplined approach to code reviews.\n- **Shared Database Hotspots**:\n  - **Mitigation**: High contention on a shared database can become a bottleneck. Introduce clear schema ownership, use view-based access to restrict data visibility, or implement data replication strategies to reduce coupling.\n## Troubleshooting\n\n### Common Issues\n\n**Skill not loading**\nCheck YAML frontmatter syntax and required fields\n\n**Token limits exceeded**\nUse progressive disclosure - move details to modules\n\n**Modules not found**\nVerify module paths in SKILL.md are correct\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``dependency-analyzer`` -- module dependency graph builder for spotting forbidden edges\n- ``module-boundary-enforcer`` -- fails the build when a module imports across a boundary\n- ``refactoring-planner`` -- ranks modules by extraction-readiness for a future split\n\nFile v1.9.12:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-modular-monolith\",\n  \"version\": \"1.9.12\",\n  \"publishedAt\": 1781838536184\n}\n\nFile v1.9.12:skill-card.md\n\n## Description: <br>\nApplies modular monolith with enforced internal boundaries. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and software architecture teams use this skill to organize large monolithic codebases into well-bounded modules with explicit internal contracts, dependency checks, and a path toward future service extraction when needed. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Generated refactoring, CI boundary checks, or ADR changes could affect downstream code or architecture if applied without review. <br>\nMitigation: Review proposed refactoring, boundary checks, and ADR updates before applying them, and scan downstream code changes through the project review process. <br>\nRisk: Module boundaries can erode over time if dependency rules are documented but not enforced. <br>\nMitigation: Use automated dependency checks and treat boundary violations as build-breaking issues. <br>\nRisk: Shared database ownership can create coupling and contention across modules. <br>\nMitigation: Define schema ownership and public data access contracts before introducing shared database interactions between modules. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-modular-monolith) <br>\n- [ClawHub metadata homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Guidance, Markdown, Configuration, Code] <br>\n**Output Format:** [Markdown architecture guidance with ADR, contract documentation, dependency-check, and CI boundary-enforcement recommendations] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Documentation-only guidance; no executable code or hidden access paths were identified in security evidence.] <br>\n\n## Skill Version(s): <br>\n1.9.12 (source: ClawHub release metadata; artifact frontmatter lists 1.9.8) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.8.6: 3 files, 3599 bytes\n\nFiles: skill-card.md (2380b), SKILL.md (4094b), _meta.json (171b)\n\nFile v1.8.6:SKILL.md\n\n---\nname: architecture-paradigm-modular-monolith\ndescription: Applies modular monolith with enforced internal boundaries\nversion: 1.9.8\ntriggers:\n  - architecture\n  - modular-monolith\n  - monolith\n  - internal-boundaries\n  - team-autonomy\n  - teams want service-level autonomy without distributed system overhead\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Modular Monolith Paradigm\n\n\n## When To Use\n\n- Organizing large codebases into well-bounded modules\n- Teams wanting microservice boundaries without distributed complexity\n\n## When NOT To Use\n\n- Already distributed as microservices\n- Tiny applications where module boundaries add unnecessary complexity\n\n## When to Employ This Paradigm\n- When you desire team autonomy similar to that of microservices, but without the operational overhead of a distributed system.\n- When release velocity is slowed by tangled dependencies between internal modules.\n- When a monolithic architecture is simpler to operate today, but there is a clear need to evolve toward a service-based model in the future.\n\n## Adoption Steps\n1. **Identify Modules**: Define module boundaries that align with distinct business capabilities or Bounded Contexts from Domain-Driven Design.\n2. **Encapsulate Internals**: Use language-level visibility modifiers (e.g., public/private), separate packages, or namespaces to hide the implementation details of each module.\n3. **Expose Public Contracts**: Each module should expose its functionality through well-defined facades, APIs, or events. Forbid direct database table access or direct implementation calls between modules.\n4. **Enforce Architectural Fitness**: Implement automated tests that fail the build if forbidden dependencies or package references are introduced between modules.\n5. **Plan for Evolution**: Continuously track metrics such as change coupling and deployment scope to make informed decisions about if and when to split a module into a separate service.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that maps module boundaries and defines the rules for any shared code.\n- Formal contract documentation (e.g., OpenAPI specs, event schemas) for every interaction point between modules.\n- Automated dependency checks and dedicated CI/CD jobs for each module to enforce boundaries.\n\n## Risks & Mitigations\n- **Regression to a \"Big Ball of Mud\"**:\n  - **Mitigation**: Without strict enforcement, module boundaries will inevitably erode. Treat any boundary violation as a build-breaking error and maintain a disciplined approach to code reviews.\n- **Shared Database Hotspots**:\n  - **Mitigation**: High contention on a shared database can become a bottleneck. Introduce clear schema ownership, use view-based access to restrict data visibility, or implement data replication strategies to reduce coupling.\n## Troubleshooting\n\n### Common Issues\n\n**Skill not loading**\nCheck YAML frontmatter syntax and required fields\n\n**Token limits exceeded**\nUse progressive disclosure - move details to modules\n\n**Modules not found**\nVerify module paths in SKILL.md are correct\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``dependency-analyzer`` -- module dependency graph builder for spotting forbidden edges\n- ``module-boundary-enforcer`` -- fails the build when a module imports across a boundary\n- ``refactoring-planner`` -- ranks modules by extraction-readiness for a future split\n\nFile v1.8.6:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-modular-monolith\",\n  \"version\": \"1.8.6\",\n  \"publishedAt\": 1780867373163\n}\n\nFile v1.8.6:skill-card.md\n\n## Description: <br>\nApplies modular monolith guidance with enforced internal boundaries. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and software architecture teams use this skill to organize large codebases into well-bounded modules, define public contracts, and enforce modular monolith boundaries without adopting distributed-service overhead. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Architecture recommendations could be applied without enough project-specific review. <br>\nMitigation: Treat the skill output as design advice and have the implementation plan reviewed by the responsible architecture and engineering owners before changing a real codebase. <br>\nRisk: Future CI or boundary-enforcement changes derived from the guidance could disrupt builds or module ownership if introduced too broadly. <br>\nMitigation: Review and stage any generated dependency checks, configuration, or build changes before applying them to production repositories. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-modular-monolith) <br>\n- [Publisher profile](https://clawhub.ai/user/athola) <br>\n- [OpenClaw homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n- [ClawHub metadata homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [guidance, markdown, configuration, shell commands] <br>\n**Output Format:** [Markdown guidance with architecture recommendations and implementation checklists] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Documentation-only skill; no executable code, dependencies, credential handling, or hidden persistence were reported by the server security evidence.] <br>\n\n## Skill Version(s): <br>\n1.8.6 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.8.5: 3 files, 3343 bytes\n\nFiles: skill-card.md (2323b), SKILL.md (3502b), _meta.json (171b)\n\nFile v1.8.5:SKILL.md\n\n---\nname: architecture-paradigm-modular-monolith\ndescription: |\n  'Single deployable with enforced module boundaries for team autonomy without distributed complexity\nversion: 1.9.5\ntriggers:\n  - architecture\n  - modular-monolith\n  - monolith\n  - internal-boundaries\n  - team-autonomy\n  - teams need autonomy without distributed overhead\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Modular Monolith Paradigm\n\n\n## When To Use\n\n- Organizing large codebases into well-bounded modules\n- Teams wanting microservice boundaries without distributed complexity\n\n## When NOT To Use\n\n- Already distributed as microservices\n- Tiny applications where module boundaries add unnecessary complexity\n\n## When to Employ This Paradigm\n- When you desire team autonomy similar to that of microservices, but without the operational overhead of a distributed system.\n- When release velocity is slowed by tangled dependencies between internal modules.\n- When a monolithic architecture is simpler to operate today, but there is a clear need to evolve toward a service-based model in the future.\n\n## Adoption Steps\n1. **Identify Modules**: Define module boundaries that align with distinct business capabilities or Bounded Contexts from Domain-Driven Design.\n2. **Encapsulate Internals**: Use language-level visibility modifiers (e.g., public/private), separate packages, or namespaces to hide the implementation details of each module.\n3. **Expose Public Contracts**: Each module should expose its functionality through well-defined facades, APIs, or events. Forbid direct database table access or direct implementation calls between modules.\n4. **Enforce Architectural Fitness**: Implement automated tests that fail the build if forbidden dependencies or package references are introduced between modules.\n5. **Plan for Evolution**: Continuously track metrics such as change coupling and deployment scope to make informed decisions about if and when to split a module into a separate service.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that maps module boundaries and defines the rules for any shared code.\n- Formal contract documentation (e.g., OpenAPI specs, event schemas) for every interaction point between modules.\n- Automated dependency checks and dedicated CI/CD jobs for each module to enforce boundaries.\n\n## Risks & Mitigations\n- **Regression to a \"Big Ball of Mud\"**:\n  - **Mitigation**: Without strict enforcement, module boundaries will inevitably erode. Treat any boundary violation as a build-breaking error and maintain a disciplined approach to code reviews.\n- **Shared Database Hotspots**:\n  - **Mitigation**: High contention on a shared database can become a bottleneck. Introduce clear schema ownership, use view-based access to restrict data visibility, or implement data replication strategies to reduce coupling.\n## Troubleshooting\n\n### Common Issues\n\n**Skill not loading**\nCheck YAML frontmatter syntax and required fields\n\n**Token limits exceeded**\nUse progressive disclosure - move details to modules\n\n**Modules not found**\nVerify module paths in SKILL.md are correct\n\nFile v1.8.5:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-modular-monolith\",\n  \"version\": \"1.8.5\",\n  \"publishedAt\": 1778292930591\n}\n\nFile v1.8.5:skill-card.md\n\n## Description: <br>\nGuides agents on applying a modular monolith architecture with enforced module boundaries for team autonomy without distributed complexity. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and software architecture teams use this skill to organize large codebases into well-bounded modules, define internal contracts, and preserve team autonomy without adopting distributed services. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may activate on broad architecture-related prompts and produce guidance that affects system design decisions. <br>\nMitigation: Review recommendations against project constraints and treat architecture boundary changes as design decisions requiring team review. <br>\nRisk: The artifact references a Claude Code plugin that is outside this scan. <br>\nMitigation: Review and scan the referenced plugin separately before installing or relying on it. <br>\nRisk: Module boundaries can erode over time or create shared database hotspots if the guidance is applied without enforcement. <br>\nMitigation: Use automated dependency checks, explicit module contracts, and schema ownership rules before depending on the architecture in production. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-modular-monolith) <br>\n- [OpenClaw homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [guidance, markdown, configuration] <br>\n**Output Format:** [Markdown architecture guidance] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Instruction-only output; no code execution, credential access, persistence, or sensitive data handling.] <br>\n\n## Skill Version(s): <br>\n1.8.5 (source: server release metadata) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>","readmeExcerpt":"Skill: architecture-paradigm-modular-monolith Owner: athola Summary: Applies modular monolith with enforced internal boundaries Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:05:41.761Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:29:33.027Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:29:20.464Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:46:27.682Z | user Release v1.9.16 v1.9.15 | 2026-07-04T21","codeSnippets":[],"executableExamples":[],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: architecture-paradigm-modular-monolith\ndescription: Applies modular monolith with enforced internal boundaries\nversion: 1.9.8\ntriggers:\n  - architecture\n  - modular-monolith\n  - monolith\n  - internal-boundaries\n  - team-autonomy\n  - teams want service-level autonomy without distributed system overhead\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# The Modular Monolith Paradigm\n\n\n## When To Use\n\n- Organizing large codebases into well-bounded modules\n- Teams wanting microservice boundaries without distributed complexity\n\n## When NOT To Use\n\n- Already distributed as microservices\n- Tiny applications where module boundaries add unnecessary complexity\n\n## When to Employ This Paradigm\n- When you desire team autonomy similar to that of microservices, but without the operational overhead of a distributed system.\n- When release velocity is slowed by tangled dependencies between internal modules.\n- When a monolithic architecture is simpler to operate today, but there is a clear need to evolve toward a service-based model in the future.\n\n## Adoption Steps\n1. **Identify Modules**: Define module boundaries that align with distinct business capabilities or Bounded Contexts from Domain-Driven Design.\n2. **Encapsulate Internals**: Use language-level visibility modifiers (e.g., public/private), separate packages, or namespaces to hide the implementation details of each module.\n3. **Expose Public Contracts**: Each module should expose its functionality through well-defined facades, APIs, or events. Forbid direct database table access or direct implementation calls between modules.\n4. **Enforce Architectural Fitness**: Implement automated tests that fail the build if forbidden dependencies or package references are introduced between modules.\n5. **Plan for Evolution**: Continuously track metrics such as change coupling and deployment scope to make informed decisions about if and when to split a module into a separate service.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that maps module boundaries and defines the rules for any shared code.\n- Formal contract documentation (e.g., OpenAPI specs, event schemas) for every interaction point between modules.\n- Automated dependency checks and dedicated CI/CD jobs for each module to enforce boundaries.\n\n## Risks & Mitigations\n- **Regression to a \"Big Ball of Mud\"**:\n  - **Mitigation**: Without strict enforcement, module boundaries will inevitably erode. Treat any boundary violation as a build-breaking error and maintain a disciplined approach to code reviews.\n- **Shared Database Hotspots**:\n  - **Miti"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-modular-monolith\",\n  \"version\": \"1.9.19\",\n  \"publishedAt\": 1787749541761\n}"},{"path":"skill-card.md","content":"## Description:\n\nApplies modular monolith with enforced internal boundaries.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[athola](https://clawhub.ai/user/athola)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and architecture teams use this skill to organize large codebases into well-bounded modules, preserve monolith operational simplicity, and enforce internal boundaries as systems grow.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Broad architecture triggers may activate the skill during general architecture conversations.\n\nMitigation: Use specific invocation language for modular monolith work, or narrow triggers when a workspace needs more selective activation.\n\nRisk: Architecture recommendations may be misapplied if module boundaries are not reviewed and enforced.\n\nMitigation: Review proposed boundaries with the engineering team and back them with dependency checks, contract documentation, and CI enforcement.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-modular-monolith)\n- [OpenClaw homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes)\n\n## Skill Output:\n\n**Output Type(s):** [Guidance, Markdown, Configuration]\n\n**Output Format:** [Markdown guidance with checklists and architecture recommendations]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [No code execution; may suggest ADRs, contract documentation, dependency checks, and CI boundary enforcement.]\n\n## Skill Version(s):\n\n1.9.19 (source: server release metadata; artifact frontmatter lists 1.9.8)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Applies modular monolith with enforced internal boundaries Skill: architecture-paradigm-modular-monolith Owner: athola Summary: Applies modular monolith with enforced internal boundaries Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:05:41.761Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:29:33.027Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:29:20.464Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:46:27.682Z | user Release v1.9.16 v1.9.15 | 2026-07-04T21","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1041,"uniquenessScore":56,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-10T02:44:55.910Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-10T02:44:55.910Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T04:36:22.864Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}