{"id":"1690f337-2e7b-4a9b-b5ea-01cbf8c14970","entityType":"agent","slug":"clawhub-athola-nm-archetypes-architecture-paradigm-service-base","name":"architecture-paradigm-service-based","canonicalUrl":"https://www.xpersona.co/agent/clawhub-athola-nm-archetypes-architecture-paradigm-service-base","canonicalPath":"/agent/clawhub-athola-nm-archetypes-architecture-paradigm-service-base","generatedAt":"2026-10-10T03:59:13.672Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-10T01:59:14.646Z","emptyReason":null},"description":"Applies coarse-grained service architecture for deployment independence Skill: architecture-paradigm-service-based Owner: athola Summary: Applies coarse-grained service architecture for deployment independence Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:05:59.045Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:29:48.031Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:29:33.676Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:46:39.175Z | user Release v1.9.16 v1.9.15 | 202","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-service-based","sourceUrl":"https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-service-based","homepage":"https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-service-based","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-service-based","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-service-based","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":40,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Applies coarse-grained service architecture for deployment independence Skill: architecture-paradigm-service-based Owner: athola Summary: Applies coarse-grained"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T01:59:14.646Z","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-10T01:59:14.646Z","emptyReason":null},"stars":null,"forks":null,"downloads":1789,"packageName":null,"latestVersion":"1.9.19","tractionLabel":"1.8K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T01:59:14.645Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T01:59:14.646Z","lastCrawledAt":"2026-10-10T01:59:14.645Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T01:59:14.645Z","lastVerifiedAt":null,"highlights":[{"version":"1.9.19","createdAt":"2026-08-26T13:05:59.045Z","changelog":"Release v1.9.19","fileCount":3,"zipByteSize":3339},{"version":"1.9.18","createdAt":"2026-08-15T21:29:48.031Z","changelog":"Release v1.9.18","fileCount":3,"zipByteSize":3475},{"version":"1.9.17","createdAt":"2026-07-30T05:29:33.676Z","changelog":"Release v1.9.17","fileCount":3,"zipByteSize":3286},{"version":"1.9.16","createdAt":"2026-07-14T19:46:39.175Z","changelog":"Release v1.9.16","fileCount":3,"zipByteSize":3457},{"version":"1.9.15","createdAt":"2026-07-04T21:20:37.514Z","changelog":"Release v1.9.15","fileCount":3,"zipByteSize":3461},{"version":"1.9.14","createdAt":"2026-06-30T17:51:16.468Z","changelog":"Release v1.9.14","fileCount":3,"zipByteSize":3397},{"version":"1.9.13","createdAt":"2026-06-27T16:15:43.338Z","changelog":"Release v1.9.13","fileCount":3,"zipByteSize":3511},{"version":"1.9.12","createdAt":"2026-06-19T03:09:06.656Z","changelog":"Release v1.9.12","fileCount":3,"zipByteSize":3312}]},"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-service-based","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-service-base/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-service-base/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-service-base/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-service-base/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-service-base/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-service-base/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-10T03:59:13.671Z"}},"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-service-base/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-service-base/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-service-base/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-service-base/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-10T01:59:14.646Z","emptyReason":null},"readme":"Skill: architecture-paradigm-service-based\n\nOwner: athola\n\nSummary: Applies coarse-grained service architecture for deployment independence\n\nTags: latest:1.9.19\n\nVersion history:\n\nv1.9.19 | 2026-08-26T13:05:59.045Z | user\n\nRelease v1.9.19\n\nv1.9.18 | 2026-08-15T21:29:48.031Z | user\n\nRelease v1.9.18\n\nv1.9.17 | 2026-07-30T05:29:33.676Z | user\n\nRelease v1.9.17\n\nv1.9.16 | 2026-07-14T19:46:39.175Z | user\n\nRelease v1.9.16\n\nv1.9.15 | 2026-07-04T21:20:37.514Z | user\n\nRelease v1.9.15\n\nv1.9.14 | 2026-06-30T17:51:16.468Z | user\n\nRelease v1.9.14\n\nv1.9.13 | 2026-06-27T16:15:43.338Z | user\n\nRelease v1.9.13\n\nv1.9.12 | 2026-06-19T03:09:06.656Z | user\n\nRelease v1.9.12\n\nv1.8.6 | 2026-06-07T21:23:01.040Z | user\n\nRelease v1.9.11\n\nv1.8.5 | 2026-05-09T02:15:34.909Z | user\n\nRelease v1.9.5\n\nv1.8.4 | 2026-05-06T14:15:23.502Z | user\n\nRelease v1.9.4\n\nv1.8.3 | 2026-04-10T05:45:57.927Z | user\n\nRelease v1.8.3\n\nArchive index:\n\nArchive v1.9.19: 3 files, 3339 bytes\n\nFiles: skill-card.md (2050b), SKILL.md (3766b), _meta.json (169b)\n\nFile v1.9.19:SKILL.md\n\n---\nname: architecture-paradigm-service-based\ndescription: Applies coarse-grained service architecture for deployment independence\nversion: 1.9.8\ntriggers:\n  - architecture\n  - service-based\n  - soa\n  - modular\n  - shared-database\n  - independent deployment is needed but shared databases rule out microservices\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 Service-Based Architecture Paradigm\n\n\n## When To Use\n\n- Multi-team organizations with domain-aligned services\n- Systems requiring independent deployment of components\n\n## When NOT To Use\n\n- Single-team projects small enough for a monolith\n- Latency-sensitive systems where inter-service calls are prohibitive\n\n## When to Employ This Paradigm\n- When teams require a degree of deployment independence but are not yet prepared for the complexity of managing numerous microservices.\n- When shared databases or large-scale systems (like ERPs) make full service autonomy unrealistic.\n- When establishing clear service contracts for partner teams or external consumers.\n\n## Adoption Steps\n1. **Group Capabilities**: Bundle related business functions into a small set of well-defined services, each with a designated owner.\n2. **Define Service Contracts**: Publish formal specifications using standards like OpenAPI or AsyncAPI, including Service Level Agreements (SLAs) and a clear versioning strategy.\n3. **Control Database Schemas**: Even when services share a database, assign explicit ownership for each schema or table. Gate all breaking changes through a formal review process.\n4. **Establish Service Mediation**: Use a service registry or an API gateway to handle routing, authentication, and observability.\n5. **Plan for Evolution**: Identify architectural \"hotspots\" that are likely candidates for being split into more granular services in the future.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that outlines service boundaries, data ownership rules, and coordination mechanisms.\n- A suite of contract tests and consumer-driven contract tests for each service to validate stability.\n- Runbooks that describe deployment procedures, rollback plans, and service dependencies.\n\n## Risks & Mitigations\n- **Coupling Through a Shared Database**:\n  - **Mitigation**: Changes to a shared database can have cascading effects across services. Mitigate this by using database views, replication, or a formal schema deprecation schedule to manage change.\n- **Architectural Degradation**:\n  - **Mitigation**: Without strong governance, this architecture can degrade into a \"distributed monolith\"—a monolith with the added complexity of network hops. Track coupling metrics closely and enforce strict ownership of services and data to prevent this.\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- ``api-gateway`` -- single ingress that routes to coarse-grained services and centralizes cross-cutting concerns\n- ``service-registry`` -- directory of available services with health status and contracts\n- ``schema-management`` -- shared schema repo for types crossing service boundaries\n\nFile v1.9.19:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-service-based\",\n  \"version\": \"1.9.19\",\n  \"publishedAt\": 1787749559045\n}\n\nFile v1.9.19:skill-card.md\n\n## Description:\n\nApplies coarse-grained service architecture for deployment independence.\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 during architecture discussions to evaluate service-based architecture for systems that need component deployment independence while retaining coarse-grained services or shared data stores.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Broad triggers such as architecture and modular may activate this guidance in unrelated architecture conversations.\n\nMitigation: Use narrower invocation patterns or review whether service-based architecture is relevant before applying the recommendations.\n\nRisk: Service-based architecture with shared databases can increase coupling or architectural drift if applied without governance.\n\nMitigation: Pair adoption with explicit data ownership, service contracts, schema change review, contract tests, and coupling metrics.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-service-based)\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, Analysis]\n\n**Output Format:** [Markdown guidance with architecture recommendations, adoption steps, deliverables, and risks.]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Documentation-only guidance; no execution, data access, or persistence is reported by the security evidence.]\n\n## Skill Version(s):\n\n1.9.19 (source: server release metadata; artifact frontmatter reports 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, 3475 bytes\n\nFiles: skill-card.md (2325b), SKILL.md (3766b), _meta.json (169b)\n\nFile v1.9.18:SKILL.md\n\n---\nname: architecture-paradigm-service-based\ndescription: Applies coarse-grained service architecture for deployment independence\nversion: 1.9.8\ntriggers:\n  - architecture\n  - service-based\n  - soa\n  - modular\n  - shared-database\n  - independent deployment is needed but shared databases rule out microservices\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 Service-Based Architecture Paradigm\n\n\n## When To Use\n\n- Multi-team organizations with domain-aligned services\n- Systems requiring independent deployment of components\n\n## When NOT To Use\n\n- Single-team projects small enough for a monolith\n- Latency-sensitive systems where inter-service calls are prohibitive\n\n## When to Employ This Paradigm\n- When teams require a degree of deployment independence but are not yet prepared for the complexity of managing numerous microservices.\n- When shared databases or large-scale systems (like ERPs) make full service autonomy unrealistic.\n- When establishing clear service contracts for partner teams or external consumers.\n\n## Adoption Steps\n1. **Group Capabilities**: Bundle related business functions into a small set of well-defined services, each with a designated owner.\n2. **Define Service Contracts**: Publish formal specifications using standards like OpenAPI or AsyncAPI, including Service Level Agreements (SLAs) and a clear versioning strategy.\n3. **Control Database Schemas**: Even when services share a database, assign explicit ownership for each schema or table. Gate all breaking changes through a formal review process.\n4. **Establish Service Mediation**: Use a service registry or an API gateway to handle routing, authentication, and observability.\n5. **Plan for Evolution**: Identify architectural \"hotspots\" that are likely candidates for being split into more granular services in the future.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that outlines service boundaries, data ownership rules, and coordination mechanisms.\n- A suite of contract tests and consumer-driven contract tests for each service to validate stability.\n- Runbooks that describe deployment procedures, rollback plans, and service dependencies.\n\n## Risks & Mitigations\n- **Coupling Through a Shared Database**:\n  - **Mitigation**: Changes to a shared database can have cascading effects across services. Mitigate this by using database views, replication, or a formal schema deprecation schedule to manage change.\n- **Architectural Degradation**:\n  - **Mitigation**: Without strong governance, this architecture can degrade into a \"distributed monolith\"—a monolith with the added complexity of network hops. Track coupling metrics closely and enforce strict ownership of services and data to prevent this.\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- ``api-gateway`` -- single ingress that routes to coarse-grained services and centralizes cross-cutting concerns\n- ``service-registry`` -- directory of available services with health status and contracts\n- ``schema-management`` -- shared schema repo for types crossing service boundaries\n\nFile v1.9.18:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-service-based\",\n  \"version\": \"1.9.18\",\n  \"publishedAt\": 1786829388031\n}\n\nFile v1.9.18:skill-card.md\n\n## Description:\n\nApplies coarse-grained service architecture for deployment independence.\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 service-based architecture fits systems that need independent component deployment while shared databases or ERP constraints make full microservices impractical. It helps outline adoption steps, service contracts, database ownership, delivery artifacts, and architecture risks.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Broad trigger words may cause the skill to appear in more conversations than intended.\n\nMitigation: Use or enable it for architecture discussions where service-based architecture, SOA, modular systems, or shared-database constraints are relevant.\n\nRisk: The artifact references a separate Claude Code plugin for the full experience.\n\nMitigation: Evaluate that plugin separately before installing it.\n\nRisk: Shared-database coupling can make changes cascade across services.\n\nMitigation: Use database views, replication, or a formal schema deprecation schedule, and assign explicit schema or table ownership.\n\nRisk: Weak governance can let a service-based architecture degrade into a distributed monolith.\n\nMitigation: Track coupling metrics and enforce clear service and data ownership.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-service-based)\n- [Clawdis homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown guidance]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Text-only advisory prompt; no code execution, data access, persistence, or hidden behavior according to ClawHub security evidence.]\n\n## Skill Version(s):\n\n1.9.18 (source: server release evidence)\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, 3286 bytes\n\nFiles: skill-card.md (2046b), SKILL.md (3766b), _meta.json (169b)\n\nFile v1.9.17:SKILL.md\n\n---\nname: architecture-paradigm-service-based\ndescription: Applies coarse-grained service architecture for deployment independence\nversion: 1.9.8\ntriggers:\n  - architecture\n  - service-based\n  - soa\n  - modular\n  - shared-database\n  - independent deployment is needed but shared databases rule out microservices\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 Service-Based Architecture Paradigm\n\n\n## When To Use\n\n- Multi-team organizations with domain-aligned services\n- Systems requiring independent deployment of components\n\n## When NOT To Use\n\n- Single-team projects small enough for a monolith\n- Latency-sensitive systems where inter-service calls are prohibitive\n\n## When to Employ This Paradigm\n- When teams require a degree of deployment independence but are not yet prepared for the complexity of managing numerous microservices.\n- When shared databases or large-scale systems (like ERPs) make full service autonomy unrealistic.\n- When establishing clear service contracts for partner teams or external consumers.\n\n## Adoption Steps\n1. **Group Capabilities**: Bundle related business functions into a small set of well-defined services, each with a designated owner.\n2. **Define Service Contracts**: Publish formal specifications using standards like OpenAPI or AsyncAPI, including Service Level Agreements (SLAs) and a clear versioning strategy.\n3. **Control Database Schemas**: Even when services share a database, assign explicit ownership for each schema or table. Gate all breaking changes through a formal review process.\n4. **Establish Service Mediation**: Use a service registry or an API gateway to handle routing, authentication, and observability.\n5. **Plan for Evolution**: Identify architectural \"hotspots\" that are likely candidates for being split into more granular services in the future.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that outlines service boundaries, data ownership rules, and coordination mechanisms.\n- A suite of contract tests and consumer-driven contract tests for each service to validate stability.\n- Runbooks that describe deployment procedures, rollback plans, and service dependencies.\n\n## Risks & Mitigations\n- **Coupling Through a Shared Database**:\n  - **Mitigation**: Changes to a shared database can have cascading effects across services. Mitigate this by using database views, replication, or a formal schema deprecation schedule to manage change.\n- **Architectural Degradation**:\n  - **Mitigation**: Without strong governance, this architecture can degrade into a \"distributed monolith\"—a monolith with the added complexity of network hops. Track coupling metrics closely and enforce strict ownership of services and data to prevent this.\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- ``api-gateway`` -- single ingress that routes to coarse-grained services and centralizes cross-cutting concerns\n- ``service-registry`` -- directory of available services with health status and contracts\n- ``schema-management`` -- shared schema repo for types crossing service boundaries\n\nFile v1.9.17:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-service-based\",\n  \"version\": \"1.9.17\",\n  \"publishedAt\": 1785389373676\n}\n\nFile v1.9.17:skill-card.md\n\n## Description: <br>\nApplies coarse-grained service architecture for deployment independence. <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 evaluate when service-based architecture is appropriate and to plan service boundaries, contracts, shared-database ownership, and operational deliverables. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The referenced upstream plugin is separate from the inspected artifact. <br>\nMitigation: Review the upstream plugin independently before installing or relying on behavior outside this skill artifact. <br>\nRisk: Architecture guidance can be misapplied to systems where shared databases or service boundaries create excessive coupling. <br>\nMitigation: Review proposed service boundaries, schema ownership, and contract changes with architecture owners before implementation. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-service-based) <br>\n- [Publisher profile](https://clawhub.ai/user/athola) <br>\n- [clawdis homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, guidance] <br>\n**Output Format:** [Markdown] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Architecture recommendations, adoption steps, deliverables, component vocabulary, and risk mitigations.] <br>\n\n## Skill Version(s): <br>\n1.9.17 (source: server 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.9.16: 3 files, 3457 bytes\n\nFiles: skill-card.md (2404b), SKILL.md (3766b), _meta.json (169b)\n\nFile v1.9.16:SKILL.md\n\n---\nname: architecture-paradigm-service-based\ndescription: Applies coarse-grained service architecture for deployment independence\nversion: 1.9.8\ntriggers:\n  - architecture\n  - service-based\n  - soa\n  - modular\n  - shared-database\n  - independent deployment is needed but shared databases rule out microservices\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 Service-Based Architecture Paradigm\n\n\n## When To Use\n\n- Multi-team organizations with domain-aligned services\n- Systems requiring independent deployment of components\n\n## When NOT To Use\n\n- Single-team projects small enough for a monolith\n- Latency-sensitive systems where inter-service calls are prohibitive\n\n## When to Employ This Paradigm\n- When teams require a degree of deployment independence but are not yet prepared for the complexity of managing numerous microservices.\n- When shared databases or large-scale systems (like ERPs) make full service autonomy unrealistic.\n- When establishing clear service contracts for partner teams or external consumers.\n\n## Adoption Steps\n1. **Group Capabilities**: Bundle related business functions into a small set of well-defined services, each with a designated owner.\n2. **Define Service Contracts**: Publish formal specifications using standards like OpenAPI or AsyncAPI, including Service Level Agreements (SLAs) and a clear versioning strategy.\n3. **Control Database Schemas**: Even when services share a database, assign explicit ownership for each schema or table. Gate all breaking changes through a formal review process.\n4. **Establish Service Mediation**: Use a service registry or an API gateway to handle routing, authentication, and observability.\n5. **Plan for Evolution**: Identify architectural \"hotspots\" that are likely candidates for being split into more granular services in the future.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that outlines service boundaries, data ownership rules, and coordination mechanisms.\n- A suite of contract tests and consumer-driven contract tests for each service to validate stability.\n- Runbooks that describe deployment procedures, rollback plans, and service dependencies.\n\n## Risks & Mitigations\n- **Coupling Through a Shared Database**:\n  - **Mitigation**: Changes to a shared database can have cascading effects across services. Mitigate this by using database views, replication, or a formal schema deprecation schedule to manage change.\n- **Architectural Degradation**:\n  - **Mitigation**: Without strong governance, this architecture can degrade into a \"distributed monolith\"—a monolith with the added complexity of network hops. Track coupling metrics closely and enforce strict ownership of services and data to prevent this.\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- ``api-gateway`` -- single ingress that routes to coarse-grained services and centralizes cross-cutting concerns\n- ``service-registry`` -- directory of available services with health status and contracts\n- ``schema-management`` -- shared schema repo for types crossing service boundaries\n\nFile v1.9.16:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-service-based\",\n  \"version\": \"1.9.16\",\n  \"publishedAt\": 1784058399175\n}\n\nFile v1.9.16:skill-card.md\n\n## Description: <br>\nApplies coarse-grained service architecture for deployment independence. <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 evaluate and describe service-based architectures for systems that need independently deployable components while retaining coarse-grained services or shared data constraints. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may appear in broad architecture or modularity conversations because of its activation keywords. <br>\nMitigation: Use the guidance when service-based architecture is relevant, and review recommendations before applying them to a system design. <br>\nRisk: Service-based guidance can still influence architecture decisions even though the skill has no executable behavior. <br>\nMitigation: Validate service boundaries, data ownership, contracts, deployment plans, and rollback plans with the responsible architecture and engineering teams. <br>\nRisk: Shared databases can couple services and degrade the architecture into a distributed monolith. <br>\nMitigation: Assign schema ownership, control breaking changes through review, track coupling, and use views, replication, or schema deprecation schedules where appropriate. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-service-based) <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] <br>\n**Output Format:** [Markdown prose with architecture checklists and recommendations] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Documentation-only guidance; no executable behavior, data access, or persistence.] <br>\n\n## Skill Version(s): <br>\n1.9.16 (source: ClawHub release evidence; 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.15: 3 files, 3461 bytes\n\nFiles: skill-card.md (2376b), SKILL.md (3766b), _meta.json (169b)\n\nFile v1.9.15:SKILL.md\n\n---\nname: architecture-paradigm-service-based\ndescription: Applies coarse-grained service architecture for deployment independence\nversion: 1.9.8\ntriggers:\n  - architecture\n  - service-based\n  - soa\n  - modular\n  - shared-database\n  - independent deployment is needed but shared databases rule out microservices\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 Service-Based Architecture Paradigm\n\n\n## When To Use\n\n- Multi-team organizations with domain-aligned services\n- Systems requiring independent deployment of components\n\n## When NOT To Use\n\n- Single-team projects small enough for a monolith\n- Latency-sensitive systems where inter-service calls are prohibitive\n\n## When to Employ This Paradigm\n- When teams require a degree of deployment independence but are not yet prepared for the complexity of managing numerous microservices.\n- When shared databases or large-scale systems (like ERPs) make full service autonomy unrealistic.\n- When establishing clear service contracts for partner teams or external consumers.\n\n## Adoption Steps\n1. **Group Capabilities**: Bundle related business functions into a small set of well-defined services, each with a designated owner.\n2. **Define Service Contracts**: Publish formal specifications using standards like OpenAPI or AsyncAPI, including Service Level Agreements (SLAs) and a clear versioning strategy.\n3. **Control Database Schemas**: Even when services share a database, assign explicit ownership for each schema or table. Gate all breaking changes through a formal review process.\n4. **Establish Service Mediation**: Use a service registry or an API gateway to handle routing, authentication, and observability.\n5. **Plan for Evolution**: Identify architectural \"hotspots\" that are likely candidates for being split into more granular services in the future.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that outlines service boundaries, data ownership rules, and coordination mechanisms.\n- A suite of contract tests and consumer-driven contract tests for each service to validate stability.\n- Runbooks that describe deployment procedures, rollback plans, and service dependencies.\n\n## Risks & Mitigations\n- **Coupling Through a Shared Database**:\n  - **Mitigation**: Changes to a shared database can have cascading effects across services. Mitigate this by using database views, replication, or a formal schema deprecation schedule to manage change.\n- **Architectural Degradation**:\n  - **Mitigation**: Without strong governance, this architecture can degrade into a \"distributed monolith\"—a monolith with the added complexity of network hops. Track coupling metrics closely and enforce strict ownership of services and data to prevent this.\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- ``api-gateway`` -- single ingress that routes to coarse-grained services and centralizes cross-cutting concerns\n- ``service-registry`` -- directory of available services with health status and contracts\n- ``schema-management`` -- shared schema repo for types crossing service boundaries\n\nFile v1.9.15:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-service-based\",\n  \"version\": \"1.9.15\",\n  \"publishedAt\": 1783200037514\n}\n\nFile v1.9.15:skill-card.md\n\n## Description: <br>\nApplies coarse-grained service architecture for deployment independence. <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 evaluate and apply service-based architecture when they need independently deployable components while managing shared databases, service contracts, and service ownership. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The artifact is documentation-only, but it references a broader external Claude Code plugin that may include agents, hooks, or commands outside this review. <br>\nMitigation: Review and scan the broader plugin separately before installing or enabling it. <br>\nRisk: Service-based architecture with shared databases can introduce cross-service coupling and brittle schema changes. <br>\nMitigation: Assign explicit schema ownership, gate breaking changes through review, and use views, replication, or formal deprecation schedules. <br>\nRisk: Weak governance can let coarse-grained services degrade into a distributed monolith. <br>\nMitigation: Track coupling, enforce service and data ownership, and keep service contracts explicit. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-service-based) <br>\n- [Archetypes plugin 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 with adoption steps, deliverables, component vocabulary, and risk mitigations] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Documentation-only; no executable behavior or hidden access reported by security evidence.] <br>\n\n## Skill Version(s): <br>\n1.9.15 (source: server release evidence; 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, 3397 bytes\n\nFiles: skill-card.md (2266b), SKILL.md (3766b), _meta.json (169b)\n\nFile v1.9.14:SKILL.md\n\n---\nname: architecture-paradigm-service-based\ndescription: Applies coarse-grained service architecture for deployment independence\nversion: 1.9.8\ntriggers:\n  - architecture\n  - service-based\n  - soa\n  - modular\n  - shared-database\n  - independent deployment is needed but shared databases rule out microservices\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 Service-Based Architecture Paradigm\n\n\n## When To Use\n\n- Multi-team organizations with domain-aligned services\n- Systems requiring independent deployment of components\n\n## When NOT To Use\n\n- Single-team projects small enough for a monolith\n- Latency-sensitive systems where inter-service calls are prohibitive\n\n## When to Employ This Paradigm\n- When teams require a degree of deployment independence but are not yet prepared for the complexity of managing numerous microservices.\n- When shared databases or large-scale systems (like ERPs) make full service autonomy unrealistic.\n- When establishing clear service contracts for partner teams or external consumers.\n\n## Adoption Steps\n1. **Group Capabilities**: Bundle related business functions into a small set of well-defined services, each with a designated owner.\n2. **Define Service Contracts**: Publish formal specifications using standards like OpenAPI or AsyncAPI, including Service Level Agreements (SLAs) and a clear versioning strategy.\n3. **Control Database Schemas**: Even when services share a database, assign explicit ownership for each schema or table. Gate all breaking changes through a formal review process.\n4. **Establish Service Mediation**: Use a service registry or an API gateway to handle routing, authentication, and observability.\n5. **Plan for Evolution**: Identify architectural \"hotspots\" that are likely candidates for being split into more granular services in the future.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that outlines service boundaries, data ownership rules, and coordination mechanisms.\n- A suite of contract tests and consumer-driven contract tests for each service to validate stability.\n- Runbooks that describe deployment procedures, rollback plans, and service dependencies.\n\n## Risks & Mitigations\n- **Coupling Through a Shared Database**:\n  - **Mitigation**: Changes to a shared database can have cascading effects across services. Mitigate this by using database views, replication, or a formal schema deprecation schedule to manage change.\n- **Architectural Degradation**:\n  - **Mitigation**: Without strong governance, this architecture can degrade into a \"distributed monolith\"—a monolith with the added complexity of network hops. Track coupling metrics closely and enforce strict ownership of services and data to prevent this.\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- ``api-gateway`` -- single ingress that routes to coarse-grained services and centralizes cross-cutting concerns\n- ``service-registry`` -- directory of available services with health status and contracts\n- ``schema-management`` -- shared schema repo for types crossing service boundaries\n\nFile v1.9.14:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-service-based\",\n  \"version\": \"1.9.14\",\n  \"publishedAt\": 1782841876468\n}\n\nFile v1.9.14:skill-card.md\n\n## Description: <br>\nApplies coarse-grained service architecture for deployment independence. <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 evaluate and apply a service-based architecture when coarse-grained services need more deployment independence than a monolith but full microservices are not practical. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Maintainer workflows may affect the wrong repository, account, or deployment if used without confirming the active context. <br>\nMitigation: Confirm the intended ClawHub repository, authenticated account, and deployment before acting, review dry-run output, and approve only the exact command intended. <br>\nRisk: A service-based architecture can retain coupling through shared databases. <br>\nMitigation: Assign explicit schema ownership, gate breaking changes through review, and use views, replication, or schema deprecation schedules to manage change. <br>\nRisk: Weak governance can turn coarse-grained services into a distributed monolith. <br>\nMitigation: Track coupling metrics, enforce service and data ownership, and maintain formal service contracts. <br>\n\n\n## Reference(s): <br>\n- [ClawHub Skill Page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-service-based) <br>\n- [Archetypes Plugin 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 prose with architecture recommendations, adoption steps, deliverables, and risk mitigations] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [None] <br>\n\n## Skill Version(s): <br>\n1.9.14 (source: 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.13: 3 files, 3511 bytes\n\nFiles: skill-card.md (2508b), SKILL.md (3766b), _meta.json (169b)\n\nFile v1.9.13:SKILL.md\n\n---\nname: architecture-paradigm-service-based\ndescription: Applies coarse-grained service architecture for deployment independence\nversion: 1.9.8\ntriggers:\n  - architecture\n  - service-based\n  - soa\n  - modular\n  - shared-database\n  - independent deployment is needed but shared databases rule out microservices\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 Service-Based Architecture Paradigm\n\n\n## When To Use\n\n- Multi-team organizations with domain-aligned services\n- Systems requiring independent deployment of components\n\n## When NOT To Use\n\n- Single-team projects small enough for a monolith\n- Latency-sensitive systems where inter-service calls are prohibitive\n\n## When to Employ This Paradigm\n- When teams require a degree of deployment independence but are not yet prepared for the complexity of managing numerous microservices.\n- When shared databases or large-scale systems (like ERPs) make full service autonomy unrealistic.\n- When establishing clear service contracts for partner teams or external consumers.\n\n## Adoption Steps\n1. **Group Capabilities**: Bundle related business functions into a small set of well-defined services, each with a designated owner.\n2. **Define Service Contracts**: Publish formal specifications using standards like OpenAPI or AsyncAPI, including Service Level Agreements (SLAs) and a clear versioning strategy.\n3. **Control Database Schemas**: Even when services share a database, assign explicit ownership for each schema or table. Gate all breaking changes through a formal review process.\n4. **Establish Service Mediation**: Use a service registry or an API gateway to handle routing, authentication, and observability.\n5. **Plan for Evolution**: Identify architectural \"hotspots\" that are likely candidates for being split into more granular services in the future.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that outlines service boundaries, data ownership rules, and coordination mechanisms.\n- A suite of contract tests and consumer-driven contract tests for each service to validate stability.\n- Runbooks that describe deployment procedures, rollback plans, and service dependencies.\n\n## Risks & Mitigations\n- **Coupling Through a Shared Database**:\n  - **Mitigation**: Changes to a shared database can have cascading effects across services. Mitigate this by using database views, replication, or a formal schema deprecation schedule to manage change.\n- **Architectural Degradation**:\n  - **Mitigation**: Without strong governance, this architecture can degrade into a \"distributed monolith\"—a monolith with the added complexity of network hops. Track coupling metrics closely and enforce strict ownership of services and data to prevent this.\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- ``api-gateway`` -- single ingress that routes to coarse-grained services and centralizes cross-cutting concerns\n- ``service-registry`` -- directory of available services with health status and contracts\n- ``schema-management`` -- shared schema repo for types crossing service boundaries\n\nFile v1.9.13:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-service-based\",\n  \"version\": \"1.9.13\",\n  \"publishedAt\": 1782576943338\n}\n\nFile v1.9.13:skill-card.md\n\n## Description: <br>\nApplies coarse-grained service architecture for deployment independence. <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 assess when coarse-grained service-based architecture fits systems that need deployment independence without full microservice autonomy. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may influence architecture decisions toward service-based architecture even when project constraints favor a monolith, microservices, or another pattern. <br>\nMitigation: Review the skill's when-to-use and when-not-to-use guidance against team size, latency constraints, database ownership, and deployment requirements before adopting the pattern. <br>\nRisk: Shared databases can create coupling between services and make changes cascade across teams. <br>\nMitigation: Assign schema or table ownership, gate breaking changes through review, and use views, replication, or schema deprecation schedules to manage change. <br>\nRisk: Weak service and data governance can turn a service-based system into a distributed monolith. <br>\nMitigation: Define service contracts, enforce ownership boundaries, track coupling metrics, and maintain runbooks for deployments, rollbacks, and dependencies. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-service-based) <br>\n- [OpenClaw homepage metadata](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, adoption steps, deliverables, and risk mitigations.] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [No code execution, persistence, credential use, or hidden data handling reported by security evidence.] <br>\n\n## Skill Version(s): <br>\n1.9.13 (source: ClawHub release evidence; 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.9.12: 3 files, 3312 bytes\n\nFiles: skill-card.md (2121b), SKILL.md (3766b), _meta.json (169b)\n\nFile v1.9.12:SKILL.md\n\n---\nname: architecture-paradigm-service-based\ndescription: Applies coarse-grained service architecture for deployment independence\nversion: 1.9.8\ntriggers:\n  - architecture\n  - service-based\n  - soa\n  - modular\n  - shared-database\n  - independent deployment is needed but shared databases rule out microservices\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 Service-Based Architecture Paradigm\n\n\n## When To Use\n\n- Multi-team organizations with domain-aligned services\n- Systems requiring independent deployment of components\n\n## When NOT To Use\n\n- Single-team projects small enough for a monolith\n- Latency-sensitive systems where inter-service calls are prohibitive\n\n## When to Employ This Paradigm\n- When teams require a degree of deployment independence but are not yet prepared for the complexity of managing numerous microservices.\n- When shared databases or large-scale systems (like ERPs) make full service autonomy unrealistic.\n- When establishing clear service contracts for partner teams or external consumers.\n\n## Adoption Steps\n1. **Group Capabilities**: Bundle related business functions into a small set of well-defined services, each with a designated owner.\n2. **Define Service Contracts**: Publish formal specifications using standards like OpenAPI or AsyncAPI, including Service Level Agreements (SLAs) and a clear versioning strategy.\n3. **Control Database Schemas**: Even when services share a database, assign explicit ownership for each schema or table. Gate all breaking changes through a formal review process.\n4. **Establish Service Mediation**: Use a service registry or an API gateway to handle routing, authentication, and observability.\n5. **Plan for Evolution**: Identify architectural \"hotspots\" that are likely candidates for being split into more granular services in the future.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that outlines service boundaries, data ownership rules, and coordination mechanisms.\n- A suite of contract tests and consumer-driven contract tests for each service to validate stability.\n- Runbooks that describe deployment procedures, rollback plans, and service dependencies.\n\n## Risks & Mitigations\n- **Coupling Through a Shared Database**:\n  - **Mitigation**: Changes to a shared database can have cascading effects across services. Mitigate this by using database views, replication, or a formal schema deprecation schedule to manage change.\n- **Architectural Degradation**:\n  - **Mitigation**: Without strong governance, this architecture can degrade into a \"distributed monolith\"—a monolith with the added complexity of network hops. Track coupling metrics closely and enforce strict ownership of services and data to prevent this.\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- ``api-gateway`` -- single ingress that routes to coarse-grained services and centralizes cross-cutting concerns\n- ``service-registry`` -- directory of available services with health status and contracts\n- ``schema-management`` -- shared schema repo for types crossing service boundaries\n\nFile v1.9.12:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-service-based\",\n  \"version\": \"1.9.12\",\n  \"publishedAt\": 1781838546656\n}\n\nFile v1.9.12:skill-card.md\n\n## Description: <br>\nNm Archetypes Architecture Paradigm Service Based helps agents apply coarse-grained service architecture guidance for deployment-independent systems. <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>\nUse this skill when an agent needs human-facing guidance for service-based architecture decisions, especially coarse-grained service boundaries and deployment independence. <br>\n\n### Deployment Geography for Use: <br>\nGlobal. <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Broad activation on general architecture prompts could cause the guidance to be applied when a more specific architecture approach is needed. <br>\nMitigation: Review whether the skill's activation scope fits the workflow before installation, and validate generated architecture recommendations against project-specific constraints. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-service-based) <br>\n- [Publisher profile](https://clawhub.ai/user/athola) <br>\n- [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, text, markdown] <br>\n**Output Format:** [Concise architecture guidance for the agent to apply in responses or planning notes.] <br>\n**Output Parameters:** [Architecture design questions or prompts involving service boundaries, deployment independence, and service-based system structure.] <br>\n**Other Properties Related to Output:** [The server security evidence describes the artifact as non-executable guidance with no persistence, credential use, or hidden data access.] <br>\n\n## Skill Version(s): <br>\n1.9.12 <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, 3176 bytes\n\nFiles: skill-card.md (1759b), SKILL.md (3766b), _meta.json (168b)\n\nFile v1.8.6:SKILL.md\n\n---\nname: architecture-paradigm-service-based\ndescription: Applies coarse-grained service architecture for deployment independence\nversion: 1.9.8\ntriggers:\n  - architecture\n  - service-based\n  - soa\n  - modular\n  - shared-database\n  - independent deployment is needed but shared databases rule out microservices\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 Service-Based Architecture Paradigm\n\n\n## When To Use\n\n- Multi-team organizations with domain-aligned services\n- Systems requiring independent deployment of components\n\n## When NOT To Use\n\n- Single-team projects small enough for a monolith\n- Latency-sensitive systems where inter-service calls are prohibitive\n\n## When to Employ This Paradigm\n- When teams require a degree of deployment independence but are not yet prepared for the complexity of managing numerous microservices.\n- When shared databases or large-scale systems (like ERPs) make full service autonomy unrealistic.\n- When establishing clear service contracts for partner teams or external consumers.\n\n## Adoption Steps\n1. **Group Capabilities**: Bundle related business functions into a small set of well-defined services, each with a designated owner.\n2. **Define Service Contracts**: Publish formal specifications using standards like OpenAPI or AsyncAPI, including Service Level Agreements (SLAs) and a clear versioning strategy.\n3. **Control Database Schemas**: Even when services share a database, assign explicit ownership for each schema or table. Gate all breaking changes through a formal review process.\n4. **Establish Service Mediation**: Use a service registry or an API gateway to handle routing, authentication, and observability.\n5. **Plan for Evolution**: Identify architectural \"hotspots\" that are likely candidates for being split into more granular services in the future.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that outlines service boundaries, data ownership rules, and coordination mechanisms.\n- A suite of contract tests and consumer-driven contract tests for each service to validate stability.\n- Runbooks that describe deployment procedures, rollback plans, and service dependencies.\n\n## Risks & Mitigations\n- **Coupling Through a Shared Database**:\n  - **Mitigation**: Changes to a shared database can have cascading effects across services. Mitigate this by using database views, replication, or a formal schema deprecation schedule to manage change.\n- **Architectural Degradation**:\n  - **Mitigation**: Without strong governance, this architecture can degrade into a \"distributed monolith\"—a monolith with the added complexity of network hops. Track coupling metrics closely and enforce strict ownership of services and data to prevent this.\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- ``api-gateway`` -- single ingress that routes to coarse-grained services and centralizes cross-cutting concerns\n- ``service-registry`` -- directory of available services with health status and contracts\n- ``schema-management`` -- shared schema repo for types crossing service boundaries\n\nFile v1.8.6:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-service-based\",\n  \"version\": \"1.8.6\",\n  \"publishedAt\": 1780867381040\n}\n\nFile v1.8.6:skill-card.md\n\n## Description: <br>\nApplies coarse-grained service architecture guidance for deployment independence. <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 evaluate when service-based architecture is appropriate, define coarse-grained service boundaries, and plan contracts, ownership, mediation, and evolution paths. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Review before execution as proposals could introduce incorrect or misleading guidance into skills. <br>\nMitigation: Review and scan skill before deployment. <br>\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-service-based) <br>\n- [Publisher profile](https://clawhub.ai/user/athola) <br>\n- [OpenClaw homepage metadata](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Text, Markdown, Guidance] <br>\n**Output Format:** [Markdown architecture guidance] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Documentation-only guidance; no code execution, persistence, or sensitive access is identified in the security evidence.] <br>\n\n## Skill Version(s): <br>\n1.8.6 (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.8.5: 3 files, 3207 bytes\n\nFiles: skill-card.md (2119b), SKILL.md (3358b), _meta.json (168b)\n\nFile v1.8.5:SKILL.md\n\n---\nname: architecture-paradigm-service-based\ndescription: |\n  Design coarse-grained service architecture for deployment independence without microservices complexity and overhead\nversion: 1.9.5\ntriggers:\n  - architecture\n  - service-based\n  - soa\n  - modular\n  - shared-database\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 Service-Based Architecture Paradigm\n\n\n## When To Use\n\n- Multi-team organizations with domain-aligned services\n- Systems requiring independent deployment of components\n\n## When NOT To Use\n\n- Single-team projects small enough for a monolith\n- Latency-sensitive systems where inter-service calls are prohibitive\n\n## When to Employ This Paradigm\n- When teams require a degree of deployment independence but are not yet prepared for the complexity of managing numerous microservices.\n- When shared databases or large-scale systems (like ERPs) make full service autonomy unrealistic.\n- When establishing clear service contracts for partner teams or external consumers.\n\n## Adoption Steps\n1. **Group Capabilities**: Bundle related business functions into a small set of well-defined services, each with a designated owner.\n2. **Define Service Contracts**: Publish formal specifications using standards like OpenAPI or AsyncAPI, including Service Level Agreements (SLAs) and a clear versioning strategy.\n3. **Control Database Schemas**: Even when services share a database, assign explicit ownership for each schema or table. Gate all breaking changes through a formal review process.\n4. **Establish Service Mediation**: Use a service registry or an API gateway to handle routing, authentication, and observability.\n5. **Plan for Evolution**: Identify architectural \"hotspots\" that are likely candidates for being split into more granular services in the future.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that outlines service boundaries, data ownership rules, and coordination mechanisms.\n- A suite of contract tests and consumer-driven contract tests for each service to validate stability.\n- Runbooks that describe deployment procedures, rollback plans, and service dependencies.\n\n## Risks & Mitigations\n- **Coupling Through a Shared Database**:\n  - **Mitigation**: Changes to a shared database can have cascading effects across services. Mitigate this by using database views, replication, or a formal schema deprecation schedule to manage change.\n- **Architectural Degradation**:\n  - **Mitigation**: Without strong governance, this architecture can degrade into a \"distributed monolith\"—a monolith with the added complexity of network hops. Track coupling metrics closely and enforce strict ownership of services and data to prevent this.\n## Troubleshooting\n\n### Common Issues\n\n**Command not found**\nEnsure all dependencies are installed and in PATH\n\n**Permission errors**\nCheck file permissions and run with appropriate privileges\n\n**Unexpected behavior**\nEnable verbose logging with `--verbose` flag\n\nFile v1.8.5:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-service-based\",\n  \"version\": \"1.8.5\",\n  \"publishedAt\": 1778292934909\n}\n\nFile v1.8.5:skill-card.md\n\n## Description: <br>\nDesign coarse-grained service architecture for deployment independence without microservices complexity and overhead. <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 decide when to apply a service-based architecture and to plan service boundaries, contracts, schema ownership, mediation, and evolution paths. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Following links to the broader Claude Code or Night Market plugin may involve installing separate files, hooks, commands, or permissions outside this reference skill. <br>\nMitigation: Review the separate package contents and permissions before installing or executing it. <br>\nRisk: Architecture guidance can be misapplied to systems where shared databases or service boundaries create excessive coupling. <br>\nMitigation: Validate service boundaries, schema ownership, contract tests, and rollback procedures with architecture review before adoption. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-service-based) <br>\n- [Clawdis 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 checklists and architecture deliverables] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Produces architecture recommendations, adoption steps, risks, mitigations, and deliverable suggestions.] <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-service-based Owner: athola Summary: Applies coarse-grained service architecture for deployment independence Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:05:59.045Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:29:48.031Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:29:33.676Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:46:39.175Z | user Release v1.9.16 v1.9.15 | 202","codeSnippets":[],"executableExamples":[],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: architecture-paradigm-service-based\ndescription: Applies coarse-grained service architecture for deployment independence\nversion: 1.9.8\ntriggers:\n  - architecture\n  - service-based\n  - soa\n  - modular\n  - shared-database\n  - independent deployment is needed but shared databases rule out microservices\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 Service-Based Architecture Paradigm\n\n\n## When To Use\n\n- Multi-team organizations with domain-aligned services\n- Systems requiring independent deployment of components\n\n## When NOT To Use\n\n- Single-team projects small enough for a monolith\n- Latency-sensitive systems where inter-service calls are prohibitive\n\n## When to Employ This Paradigm\n- When teams require a degree of deployment independence but are not yet prepared for the complexity of managing numerous microservices.\n- When shared databases or large-scale systems (like ERPs) make full service autonomy unrealistic.\n- When establishing clear service contracts for partner teams or external consumers.\n\n## Adoption Steps\n1. **Group Capabilities**: Bundle related business functions into a small set of well-defined services, each with a designated owner.\n2. **Define Service Contracts**: Publish formal specifications using standards like OpenAPI or AsyncAPI, including Service Level Agreements (SLAs) and a clear versioning strategy.\n3. **Control Database Schemas**: Even when services share a database, assign explicit ownership for each schema or table. Gate all breaking changes through a formal review process.\n4. **Establish Service Mediation**: Use a service registry or an API gateway to handle routing, authentication, and observability.\n5. **Plan for Evolution**: Identify architectural \"hotspots\" that are likely candidates for being split into more granular services in the future.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that outlines service boundaries, data ownership rules, and coordination mechanisms.\n- A suite of contract tests and consumer-driven contract tests for each service to validate stability.\n- Runbooks that describe deployment procedures, rollback plans, and service dependencies.\n\n## Risks & Mitigations\n- **Coupling Through a Shared Database**:\n  - **Mitigation**: Changes to a shared database can have cascading effects across services. Mitigate this by using database views, replication, or a formal schema deprecation schedule to manage change.\n- **Architectural Degradation**:\n  - **Mitigation**: Without strong governance, this architecture can degrade into a \"distributed monolith\"—a monolith with the added com"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-service-based\",\n  \"version\": \"1.9.19\",\n  \"publishedAt\": 1787749559045\n}"},{"path":"skill-card.md","content":"## Description:\n\nApplies coarse-grained service architecture for deployment independence.\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 during architecture discussions to evaluate service-based architecture for systems that need component deployment independence while retaining coarse-grained services or shared data stores.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Broad triggers such as architecture and modular may activate this guidance in unrelated architecture conversations.\n\nMitigation: Use narrower invocation patterns or review whether service-based architecture is relevant before applying the recommendations.\n\nRisk: Service-based architecture with shared databases can increase coupling or architectural drift if applied without governance.\n\nMitigation: Pair adoption with explicit data ownership, service contracts, schema change review, contract tests, and coupling metrics.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-service-based)\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, Analysis]\n\n**Output Format:** [Markdown guidance with architecture recommendations, adoption steps, deliverables, and risks.]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Documentation-only guidance; no execution, data access, or persistence is reported by the security evidence.]\n\n## Skill Version(s):\n\n1.9.19 (source: server release metadata; artifact frontmatter reports 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 coarse-grained service architecture for deployment independence Skill: architecture-paradigm-service-based Owner: athola Summary: Applies coarse-grained service architecture for deployment independence Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:05:59.045Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:29:48.031Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:29:33.676Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:46:39.175Z | user Release v1.9.16 v1.9.15 | 202","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1047,"uniquenessScore":56,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-10T01:59:14.646Z","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-10T01:59:14.646Z","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-10T03:59:13.672Z","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"}]}}}