AgentSkillsCN

architecture-monolith

对于那些以事务一致性、操作简便、并在单一可部署单元内实现快速团队迭代为优先考量的系统，可采用模块化单体架构设计。当需界定系统边界、模块间关系，以及架构层面的约束时，可选用此流程；但若仅对单个模块进行重构且不涉及架构层面的影响，则不宜使用。

SKILL.md
--- frontmatter
name: architecture-monolith
description: "Modular monolith architecture design for systems that prioritize transactional consistency, simple operations, and fast team iteration in a single deployable unit. Use when system boundaries, module relationships, and architecture-level constraints are being defined; do not use for single-module implementation refactors without architecture impact."

Architecture Monolith

Trigger Boundary

  • •Use when one deployable unit is acceptable and operational simplicity is prioritized.
  • •Do not use when independent scaling or deployment by domain is mandatory; use architecture-microservices.
  • •Do not use for async integration-first topology; use architecture-event-driven.

Goal

Design a modular monolith with clear internal boundaries and low coupling.

Shared Architecture Contract (Canonical)

  • •Use skills/architecture-principles/references/architecture-governance-contract.md as the only schema source.
  • •Validate all IDs, lifecycle states, and gate rules against the canonical contract.
  • •Do not define local ID formats or alternate state machines.

Compliance & Governance Baseline (US, Japan, EU)

  • •Isolate sensitive data handling modules and enforce least privilege.
  • •Centralize audit logging and retention controls for regulated data.
  • •Prepare an ARC-CMP-* evidence package for governance review.

Inputs

  • •Domain boundaries and transactional requirements
  • •Team size and release cadence
  • •Performance, reliability, and compliance constraints

Outputs

  • •Module boundary map and dependency rules
  • •Internal contract definitions and ownership map
  • •Evolution seams for future extraction if needed

Workflow

  1. •Partition domains into high-cohesion modules.
  2. •Define strict dependency direction across modules.
  3. •Establish module-level API contracts and ownership.
  4. •Design transactional boundaries and failure behavior.
  5. •Identify extraction seams and record migration risks.

Quality Gates

  • •Module boundaries align with domain responsibilities.
  • •Cross-module dependencies follow explicit rules.
  • •ARC-CMP-* evidence package is complete and approved.
  • •Greenfield designs exclude fallback paths; brownfield rollback requires trigger and runbook.

Failure Handling

  • •Rework when cyclic dependencies appear between modules.
  • •Stop when canonical contract validation fails.
  • •Escalate when module ownership cannot be assigned clearly.