When to Use
- Research domain decomposition, bounded contexts, and candidate service boundaries
- Compare microservices vs modular monolith (or other styles) with explicit trade-offs
- Analyze sync vs async integration, data ownership, and consistency models at decision level
- Evaluate saga vs 2PC, outbox, and choreography/orchestration without implementation tutorials
- Define API and contract evolution strategy (versioning, compatibility, deprecation)
- Plan monolith-to-microservices migration (strangler, parallel run, cutover criteria)
- Align services with Team Topologies (stream-aligned, platform, enabling, complicated-subsystem)
- Assess build vs buy vs managed for cross-cutting capabilities
- Quantify NFR impact (latency budgets, reliability, operability, cost) per boundary option
- Produce ADRs, options matrices, and research memos with a clear recommendation
When NOT to Use
- Write or refactor production microservice code, handlers, or deployables →
senior-software-engineer - Operate Kubernetes clusters, Terraform modules, or CI/CD pipelines only →
platform-engineer,cloud-engineer,infrastructure-engineer - Design carrier/WAN routing, VPC topology, or physical network without application boundaries →
network-backbone-architect - Implement brokers, outbox consumers, schema registry ops, or stream processing →
event-driven-architecture(when building),microservices-developer - Enterprise portfolio strategy, operating model, and board-level where-to-play →
enterprise-strategist - Load-test execution, caching implementation, and horizontal scale tuning only →
high-concurrency-scalability - Cross-domain system architecture sign-off unrelated to service decomposition →
senior-system-architecture(hand off when scope is whole-estate ADR) - Inventory, dependency maps, SLO gaps, API drift, or operational health on a live estate →
microservices-analyst
Related skills
| Need | Skill |
|---|---|
| Existing estate inventory, coupling, SLO/API drift, ops health | microservices-analyst |
| Cross-system ADRs, C4, estate-wide NFR sign-off | senior-system-architecture |
| Event contracts, brokers, outbox, sagas (implementation) | event-driven-architecture |
| Service code, gRPC/REST, twelve-factor deployables | senior-software-engineer, microservices-developer |
| IDP, golden paths, paved roads | platform-engineer |
| Cloud landing zone, IaC, cluster delivery | infrastructure-engineer, cloud-engineer |
| Application throughput, caching, scale testing | high-concurrency-scalability |
| Enterprise strategy, portfolio, org design | enterprise-strategist |
| Enterprise API hub, iPaaS, B2B integration programs | enterprise-integration-api-developer |
| Rollout, cutover, and rollback tactics | deployment-strategist |
Core Workflows
1. Frame the research question
Capture before comparing boundaries:
- Business capability and measurable outcome
- Constraints: teams, timeline, compliance, existing monolith/estate
- Reversibility (one-way vs two-way door)
- Non-goals and explicit out-of-scope peers
See references/microservice_researcher_scope.md.
2. Decompose the domain
Identify bounded contexts, ubiquitous language, and context maps (upstream/downstream, ACL, OHS).
Produce candidate services with ownership hypotheses—not a box diagram without data flow.
See references/domain_decomposition_and_boundaries.md.
3. Integration and consistency
For each boundary, document sync/async choice, data ownership, consistency model, and failure semantics.
Compare eventual consistency, saga compensation, and 2PC only when research warrants—not as default distributed transactions.
See references/integration_patterns_and_consistency.md.
4. Contracts and evolution
Define public API/event contracts, versioning rules, compatibility matrix, and deprecation timeline.
See references/api_contracts_and_evolution.md.
5. Migration and organization
Plan strangler slices, parity criteria, dual-write/read duration, and team alignment (Team Topologies).
See references/migration_strangler_and_org_alignment.md.
6. Deliverables and decision record
Package options matrix, NFR table, risks, recommendation, and follow-on owners (build vs research complete).
See references/research_deliverables_and_decision_records.md.
Principles
- Research before split—boundaries follow domain and team cognition, not org chart alone
- Prefer reversible experiments—strangler slices over big-bang when uncertainty is high
- One writer per aggregate—document who owns each consistency boundary
- Make trade-offs explicit—latency, ops burden, and team autonomy in the same table
- Cite patterns and literature—DDD, Team Topologies, enterprise integration patterns—without cargo-culting microservices