用途：设计或评审微服务架构，把服务边界对齐业务领域，而非按数据表拆 CRUD。核心原则是：微服务是可独立部署的业务边界，应取能保持自治与清晰的最少服务数。
主要能力：限界上下文划分（一个服务一个上下文、独立语言、公开 API 稳定、内部模型私有，禁止两个服务共享同一写库）；通信方式选择（HTTP/gRPC 同步用于需即时响应的查询与命令，消息队列/总线用于领域事件与解耦写入，Outbox/Inbox 保证事件可靠发布）；数据与一致性（每服务独立数据库或 schema、跨上下文最终一致、Saga/流程管理器处理多服务工作流、避免分布式 2PC、组合读取用 BFF 或物化视图）；拓扑（客户端→网关/BFF→服务→数据库/队列/缓存，网关只做边界鉴权、限流与路由）；可观测性与运维（结构化日志、分布式追踪、RED/USE 指标、/live 与 /ready 健康检查、按服务设 SLO、独立部署与回滚、特性开关、契约测试）；安全（内部零信任、mTLS 或服务间令牌、在资源属主服务做鉴权、密钥入 vault、最小权限）。
使用方式：资料未提供具体安装或调用命令，仅给出相关技能引用，如实现类 golang-microservices、nestjs-microservices、rust-microservices，契约 api-design，上线 production-readiness，先合并再拆分 modular-monolith，上下文 ddd，事件 event-driven-architecture，决策 software-architecture。
适用场景：团队自治、扩缩容需求不同、发布周期不同、故障需隔离时。
限制与反模式：领域不确定、团队小、服务间强延迟、缺乏可观测性运维时不宜采用；避免按实体拆服务、共享数据库与跨服务 join、无缓存聚合的频繁同步调用、把事件当耦合的异步 RPC、领域未稳就过早分布式。完成标准包括边界按领域、通信超时与幂等明确、无共享写库、每服务可观测与健康检查、与单体/模块化单体的权衡有记录。