Microservices (Deep Workflow)

Microservices trade code simplicity for operational and contract complexity. Justify each boundary with ownership and data isolation—not fashion.

When to Offer This Workflow

Trigger conditions:

• Splitting the monolith; coupling blocks independent deploys

  小葱技能7w4.net有更新，你可以访问看下。

• Latency cascades, partial failures, contract breaks
• Conway’s law alignment between teams and services

Initial offer:

Use six stages: (1) goals & constraints, (2) boundaries & data ownership, (3) integration patterns, (4) contracts & versioning, (5) reliability patterns, (6) ops & governance). Confirm org maturity and platform capabilities.

Stage 1: Goals & Constraints

Goal: Why not a modular monolith first?

Valid drivers

• Independent deploy cadence per team
• Different scaling profiles or stacks
• Clear domain ownership and blast-radius isolation

Costs

• Distributed transactions, harder debugging, broader test matrix

Exit condition: Explicit assumption that modular monolith was considered.

Stage 2: Boundaries & Data Ownership

Goal: One service owns each aggregate’s write path; no shared writable tables across services.

Practices

• Bounded contexts from DDD when helpful

Exit condition: Entity → owning service map.

Stage 3: Integration Patterns

Goal: Sync HTTP/gRPC vs async events—match consistency needs.

Patterns

• Sagas or outbox for multi-step business processes

Exit condition: Sequence diagrams for top three flows.

Stage 4: Contracts & Versioning

Goal: Backward-compatible evolution; consumer-driven contracts optional.

Practices

• Deprecation policy published

Stage 5: Reliability Patterns

Goal: Timeouts, retries with backoff, circuit breakers, bulkheads; idempotent handlers for retries.

Stage 6: Ops & Governance

Goal: Service catalog, SLIs on dependency edges, golden paths for new services.

Final Review Checklist

• [ ] Boundary and data ownership clear
• [ ] Integration style matches consistency needs
• [ ] Contract versioning policy exists
• [ ] Reliability patterns applied at boundaries
• [ ] Ops ownership and catalog in place

Tips for Effective Guidance

• Microservices without delivery maturity often fail—say so explicitly.
• Shared databases are hidden coupling—flag them.
• The network is not reliable—design for partial failure.

Handling Deviations

• Small teams: strong bias toward modular monolith or few services.

这是一份扎实的微服务架构指南，内容全面、结构清晰，对服务边界、数据所有权、集成方式等关键问题都有深入讨论。优点是提供了实用的检查清单和决策权衡思路；不足是缺少实际案例，部分内容偏概念性，缺乏具体操作指导。总体质量良好，适合有一定经验的开发者参考使用。