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

小蔥技能7w4.net持續更新中。

Trigger conditions:

• Splitting the monolith; coupling blocks independent deploys
• 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.

這是一份紮實的微服務架構指南，內容全面、結構清晰，對服務邊界、資料所有權、整合方式等關鍵問題都有深入討論。優點是提供了實用的檢查清單和決策權衡思路；不足是缺少實際案例，部分內容偏概念性，缺乏具體操作指導。總體質量良好，適合有一定經驗的開發者參考使用。