Service Granularity Evaluation Rubric Prompt

This prompt is for engineering leads and architects who need a structured, repeatable way to evaluate a concrete service proposal before writing an Architecture Decision Record or committing engineering resources. The job-to-be-done is risk reduction: catching boundaries that are too fine (nano-services with high coordination tax), too coarse (mini-monoliths that defeat the purpose of extraction), or misaligned with team structures and data ownership. You should have a defined service scope in hand—a specific candidate with a name, a set of responsibilities, a proposed data ownership model, and a known team assignment. This is not a blank-slate decomposition exercise; use the Bounded Context Discovery Prompt or Event Storming Session Synthesis Prompt for earlier-stage boundary exploration.

The prompt produces a scored rubric across multiple dimensions: cognitive load, data autonomy, team alignment, change independence, integration surface area, and operational isolation. Each dimension receives a score and a justification grounded in the evidence you provide. The output includes threshold-based pass/fail criteria (e.g., a service scoring below 3 on data autonomy should not proceed without redesign) and concrete right-sizing recommendations—split, merge, or proceed. Use this during architecture review sessions, before writing service extraction ADRs, or when a team proposes a new service that triggers your spidey sense about granularity risk. The prompt assumes you can describe the proposal in enough detail to populate the [SERVICE_PROPOSAL] placeholder with scope, data, team, and dependency information.

Do not use this prompt when the proposal is still vague, when you are exploring greenfield decomposition from scratch, or when the real question is about team topology rather than service boundaries (use the Service Boundary Team Topology Alignment Prompt for that). Do not use it as a substitute for the Distributed Monolith Risk Detection Prompt if your primary concern is post-hoc smell detection in an existing system. After running this evaluation, the next step is typically to document the decision using the Service Boundary Decision Record Template Prompt, or to proceed to Transaction Boundary Analysis if the service spans business operations that require consistency guarantees. If the rubric returns a borderline score, escalate to a human architecture review session rather than treating the model's recommendation as a final gate.

The prompt below is designed to be pasted directly into your AI system. It evaluates a proposed service boundary against eight dimensions—cognitive load, data ownership, team alignment, change frequency, coupling isolation, transaction consistency, operational independence, and blast radius—and produces a scored rubric with pass/fail thresholds and right-sizing recommendations. Replace every square-bracket placeholder with your specific service proposal details before running the evaluation.

textCopy
You are a service architecture evaluator. Your task is to assess the granularity of a proposed service using a structured rubric. Return only valid JSON matching the output schema.

## SERVICE PROPOSAL
- Service Name: [SERVICE_NAME]
- Description: [SERVICE_DESCRIPTION]
- Owned Data Entities: [OWNED_DATA_ENTITIES]
- Inbound Dependencies: [INBOUND_DEPENDENCIES]
- Outbound Dependencies: [OUTBOUND_DEPENDENCIES]
- Assigned Team Size: [TEAM_SIZE]
- Expected Change Frequency: [CHANGE_FREQUENCY]
- Business Criticality (Low/Medium/High): [BUSINESS_CRITICALITY]
- Transaction Boundaries Crossed: [TRANSACTION_BOUNDARIES_CROSSED]
- Current System Context: [SYSTEM_CONTEXT]

## EVALUATION DIMENSIONS
Score each dimension from 1 (problematic) to 5 (optimal). Provide a one-sentence justification for each score.

1. Cognitive Load: Can a single team understand the service's full responsibility without external context?
2. Data Ownership: Does the service own its data exclusively, with no shared databases or tables?
3. Team Alignment: Does the service map cleanly to one team with clear ownership boundaries?
4. Change Frequency Isolation: Can this service be deployed independently when its requirements change?
5. Coupling Isolation: Are inbound and outbound dependencies minimal, asynchronous, and versioned?
6. Transaction Consistency: Are atomic transaction boundaries contained within this service?
7. Operational Independence: Can this service be deployed, scaled, and monitored independently?
8. Blast Radius Containment: Does a failure in this service have a bounded, predictable impact?

## OUTPUT SCHEMA
{
  "service_name": "string",
  "evaluation_date": "YYYY-MM-DD",
  "dimension_scores": [
    {
      "dimension": "string",
      "score": 1-5,
      "justification": "string"
    }
  ],
  "overall_score": 1-5,
  "pass_fail": "PASS" | "FAIL" | "BORDERLINE",
  "pass_threshold": 3.5,
  "granularity_assessment": "TOO_FINE" | "APPROPRIATE" | "TOO_COARSE",
  "distributed_monolith_risk": "LOW" | "MEDIUM" | "HIGH",
  "right_sizing_recommendations": [
    {
      "action": "MERGE" | "SPLIT" | "EXTRACT" | "KEEP",
      "target": "string",
      "rationale": "string",
      "priority": "HIGH" | "MEDIUM" | "LOW"
    }
  ],
  "migration_sequencing_notes": "string",
  "review_gate_recommendation": "PROCEED" | "REVIEW_REQUIRED" | "BLOCKED"
}

## CONSTRAINTS
- Score conservatively. When uncertain, score lower and flag for human review.
- If [BUSINESS_CRITICALITY] is HIGH, require REVIEW_REQUIRED or BLOCKED for any FAIL result.
- If any dimension scores 1, overall_score must be FAIL regardless of average.
- If three or more dimensions score 2, set distributed_monolith_risk to HIGH.
- Justifications must reference specific evidence from the SERVICE PROPOSAL fields.
- Do not invent data. If information is missing, note it in the justification and score conservatively.

Adaptation guidance: The eight dimensions are calibrated for microservice decomposition decisions, but you can add or remove dimensions based on your architecture standards. If your organization uses fitness functions, add a ninth dimension that scores the service against your automated boundary tests. For teams using Team Topologies, expand the Team Alignment dimension to distinguish stream-aligned, enabling, and platform teams. The pass threshold of 3.5 is a starting point—adjust it based on your risk tolerance. For high-compliance environments, raise the threshold to 4.0 and require human review for any score below 3.

What to do next: After running this prompt, feed the output into your architecture decision record template. If the result is BORDERLINE or FAIL, run the Distributed Monolith Risk Detection Prompt next to get a detailed risk register before making a boundary decision. Always validate the AI's scoring against your own team's experience—this rubric accelerates judgment but does not replace it.

This prompt is designed to be called programmatically as part of an architecture review pipeline, not as a one-off chat interaction. The typical integration point is a pull request or design document review workflow where a proposed service boundary is submitted for automated evaluation before human architecture review. The harness should accept a structured input payload containing the service description, bounded context map, dependency graph, and team topology, then return a scored rubric with pass/fail thresholds and right-sizing recommendations. Because architecture decisions carry high blast radius, the harness must treat this as an advisory signal that feeds into human decision-making, not as an automated gate that blocks or approves designs.

Wire the prompt into an application by building a thin service that: (1) validates the input payload against a schema before calling the model, (2) injects the validated fields into the prompt template's placeholders, (3) calls the model with a low temperature (0.0–0.2) for scoring consistency, (4) parses the JSON output and validates it against the expected rubric schema, (5) retries once with a repair prompt if parsing fails, and (6) logs the full prompt, response, and parsed scores for auditability. The output schema should include dimensions (an array of scored criteria with name, score, threshold, pass, and evidence fields), overall_pass (boolean), risk_flags (array of strings), and right_sizing_recommendation (one of merge, split, keep, or re-evaluate). If the model returns a score within 10% of a threshold boundary, flag it for human review rather than accepting the automated pass/fail determination.

Model choice matters here. Use a model with strong reasoning and structured output capabilities—GPT-4o, Claude 3.5 Sonnet, or equivalent. Avoid smaller or faster models for this task because the evaluation requires holding multiple architectural dimensions in context simultaneously. If you are running this in a CI/CD pipeline, cache results keyed on a hash of the input to avoid re-evaluating unchanged proposals. Never use this prompt's output as the sole justification for an architecture decision. Always route the scored rubric to a human architect or architecture review board, and include the raw model response alongside the parsed scores so reviewers can audit the reasoning. The most common production failure mode is the model accepting a service boundary that looks clean on paper but ignores undocumented organizational constraints—human review is the safety net for what the prompt cannot see.