Domain-Driven Design Maturity Assessment Rubric Prompt

This prompt is for engineering leaders, principal architects, and technical directors who need to assess a team's or organization's current level of Domain-Driven Design (DDD) adoption. The job-to-be-done is not to generate a generic score, but to produce a structured, evidence-backed maturity model that benchmarks current practices against DDD tactical patterns, strategic design, team alignment, and ubiquitous language discipline. The ideal user has access to artifacts such as code repositories, event schemas, context maps, team topologies, and recent architecture decision records. Without this context, the assessment will be speculative and low-value.

Use this prompt when you are planning a DDD transformation, auditing a bounded context implementation, preparing for a technical due diligence review, or aligning multiple teams on a shared maturity baseline. The rubric it produces should be actionable: each maturity level must include concrete improvement steps, not just a score. Do not use this prompt for a single code review, a junior developer's learning exercise, or a lightweight design critique. It is also not a substitute for a full sociotechnical architecture assessment that requires stakeholder interviews and runtime observability data. The prompt works best when you provide a [CONTEXT] block containing specific evidence—code samples, context map diagrams described in text, event schemas, team structure descriptions, and known pain points. Without this evidence, the model will produce a plausible but ungrounded rubric that can mislead decision-making.

Before running this prompt, gather at least three types of evidence: tactical artifacts (aggregate definitions, domain events, repository patterns), strategic artifacts (bounded context boundaries, context maps, subdomain classifications), and team artifacts (team-to-context alignment, communication patterns, ownership maps). The prompt is designed to flag missing evidence rather than hallucinate it, but you should still review the output against your own knowledge. The resulting rubric should be treated as a working document for a workshop or architecture review session, not as a final audit report. If the assessment will influence budget, team structure, or architectural direction, schedule a human review with the domain architects who own the assessed contexts.

The following prompt template is designed to be copied directly into your AI harness. It uses square-bracket placeholders for all dynamic inputs, allowing you to adapt it to different teams, codebases, and assessment scopes without rewriting the core instructions. The template assumes you have gathered evidence about the team's current practices—this evidence should be provided in the [EVIDENCE] placeholder as structured notes, interview summaries, or artifact descriptions.

textCopy
You are a domain-driven design (DDD) coach and technical assessor. Your task is to evaluate a team's DDD maturity based on the provided evidence and produce a scored rubric with actionable improvement steps.

## Assessment Scope
[ASSESSMENT_SCOPE: e.g., "the Order Management bounded context and its integration with the Fulfillment context"]

## Evidence
[EVIDENCE: structured notes, interview summaries, codebase observations, documentation review]

## Assessment Dimensions
Evaluate maturity across these dimensions using a 1-5 scale (1=Absent, 2=Initial, 3=Emerging, 4=Consistent, 5=Optimizing):

1. **Strategic Design**: Bounded context identification, context mapping, subdomain classification, and alignment with business strategy.
2. **Tactical Design**: Aggregate design, entity and value object modeling, domain events, repositories, and factories.
3. **Ubiquitous Language**: Consistency of terminology across code, conversations, documentation, and tests.
4. **Team Alignment**: Team topology matching bounded contexts, domain expertise distribution, and cross-team communication patterns.
5. **Integration Patterns**: Explicit context relationships, anti-corruption layers, published languages, and integration testing.
6. **Domain Model Quality**: Behavior richness, encapsulation, invariant enforcement, and absence of anemic patterns.

## Output Schema
Return a JSON object with this exact structure:
{
  "assessment_summary": "2-3 sentence overall maturity summary",
  "overall_score": number (average of dimension scores, rounded to 1 decimal),
  "dimensions": [
    {
      "name": "dimension name",
      "score": number (1-5),
      "rationale": "2-3 sentences explaining the score with evidence references",
      "strengths": ["specific strength 1", "specific strength 2"],
      "gaps": ["specific gap 1", "specific gap 2"],
      "improvement_actions": [
        {
          "action": "concrete, actionable step",
          "effort": "Low | Medium | High",
          "impact": "Low | Medium | High",
          "timeline": "Immediate | Short-term | Medium-term | Long-term"
        }
      ]
    }
  ],
  "critical_risks": ["risk 1 if maturity gaps are not addressed", "risk 2"],
  "recommended_sequence": ["ordered list of the top 3-5 actions to take first"]
}

## Constraints
- Base every score and finding on evidence provided in [EVIDENCE]. If evidence is insufficient for a dimension, score it as "Insufficient Data" and note what evidence would be needed.
- Do not inflate scores. Most teams score 2-3 on most dimensions. A score of 4 or 5 requires clear, specific evidence of consistent practice.
- Improvement actions must be concrete and actionable, not vague advice like "improve modeling."
- Flag any contradictions in the evidence rather than silently choosing one interpretation.
- If the evidence describes aspirations rather than current practices, score the current state and note the gap.

To adapt this template, replace each square-bracket placeholder with your specific context. The [ASSESSMENT_SCOPE] should narrow the evaluation to a specific bounded context or set of contexts—avoid assessing an entire enterprise in one run. The [EVIDENCE] placeholder works best with structured input: include notes from event storming sessions, code review observations, team interview summaries, and documentation samples. If you have existing architecture decision records or context maps, include those as well. For teams new to DDD, you may want to add an [EXAMPLES] placeholder with a scored example dimension to calibrate the model's expectations. Before running this in production, validate the output JSON against the schema and spot-check at least two dimension scores against your own judgment to detect calibration drift.

This prompt is designed to be called programmatically as part of an architecture review pipeline, not as a one-off chat interaction. The primary integration points are a CI/CD quality gate for domain model changes, a quarterly architecture health check, or a pre-refactor assessment tool. The caller must supply the [DOMAIN_ARTIFACTS] (code, docs, event schemas, context maps) and the [ASSESSMENT_DIMENSIONS] (tactical patterns, strategic design, team alignment, ubiquitous language). The prompt returns a structured JSON rubric, making it suitable for direct ingestion into a dashboard or report generator.

Validation and Retry Logic: The output must conform to a strict JSON schema with numeric scores, textual evidence, and actionable recommendations. Implement a post-generation validator that checks for: (1) all required dimensions present, (2) scores within the defined 1-5 range, (3) evidence fields are non-empty strings, and (4) improvement steps are concrete and non-generic. If validation fails, retry with the error message appended to the [CONSTRAINTS] field, up to a maximum of 2 retries. Log all validation failures for prompt refinement. Model Choice: Use a model with strong reasoning capabilities (e.g., GPT-4o, Claude 3.5 Sonnet) because the task requires synthesizing multiple artifacts and applying nuanced DDD heuristics. Avoid smaller or faster models that may produce plausible-sounding but logically inconsistent assessments.

Human Review Gate: This assessment informs architectural decisions that can have long-term cost and complexity implications. Always route the output to a human reviewer (e.g., a domain architect or technical lead) before publishing or acting on the results. The review interface should display the score, the cited evidence, and the recommended improvements side-by-side, allowing the reviewer to accept, override, or annotate each finding. Logging and Audit Trail: Store the full prompt input, model response, validation results, and human review decisions in an audit log. This traceability is critical for governance and for debugging assessment drift over time. What to Avoid: Do not use this prompt as a real-time gate in a deployment pipeline without human review. Do not treat the numeric score as an objective metric without examining the evidence. Do not run the assessment on artifacts that are incomplete or lack sufficient context, as the model will hallucinate plausible but incorrect findings.