用途：在开始设计微服务架构之前，提供可复用的判断依据、领域约束与工作流，帮助团队有意识地选择单体或微服务，并给出分解、数据隔离与迁移的指导。
主要能力：
- 单体与微服务的取舍对比，覆盖团队规模、部署、可扩展性、复杂度、技术栈、数据、故障、测试与启动速度等因素。资料强调不要默认推荐微服务，团队小于 10 人、限界上下文不清晰、MVP 或概念验证阶段可保持单体。
- 分解模式：按业务能力分解（推荐），按 DDD 子域分解；跨子域只通过 API 通信，绝不共享表。附学校管理系统示例，含 enrollment-service、academic-service、finance-service、communication-service、ai-service、identity-service。
- 迁移路径：Strangler Fig 模式，先在单体前放 API 网关或反向代理，逐个抽取服务并转移流量，最后下线单体。资料强调在理解边界之前不要拆分服务，错误拆分会产生“分布式单体”。
- 适配微服务的 12-Factor：每个服务独立代码库、显式依赖、环境变量配置、外部服务视为附加资源、构建/发布/运行分离、无状态进程、数据隔离、独立横向扩展、快速启动与优雅关闭、开发生产一致、日志作为事件流、管理任务作为一次性进程。
- 限界上下文与数据隔离：每个服务拥有自己的数据，其他服务只能通过其 API 访问，不得直接读写数据库；跨服务报表可用事件驱动读模型或 BFF 聚合层。无状态服务示例将会话存入 Redis 等外部服务。
使用方式：先读 SKILL.md，再按需加载其引用的深入文件，不要默认加载全部参考文件；按顺序应用其中的指南、清单与决策规则，而不是摘取孤立片段；产出需为具体结果并明确假设、风险与后续工作。
适用场景：设计微服务前评估架构、服务分解、数据隔离、无状态设计、从单体迁移的规划与评审。
限制：不适用于与微服务基础无关的任务，或存在更具体的配套技能时；也不适用于仅需简单回答且这些约束无实质帮助的请求。资料未提供该技能的安装命令、价格、平台或效果信息。