Skip to content

Strategic Domain Design (SDD)

Stage: Stage 3 - Strategic Domain Design

Artifact Code: SDD

1. Purpose

The Strategic Domain Design (SDD) exists to assemble all approved business understanding into a single, coherent domain specification.

It is the authoritative business model of the initiative:

  • how the organization is structured,
  • how work flows through it,
  • who is responsible for what,
  • what business records exist,
  • and which strategic rules govern behavior.

The SDD is the final output of Strategic Domain Design and the only acceptable input to Technical Domain Design (Stage 4).

2. Decision This Artifact Supports

Decision: Is the business domain sufficiently clear, complete, and stable to translate into technical design?

Possible outcomes:

  • Accept SDD and proceed to Stage 4 (TDD)
  • Revise SDD (gaps, inconsistencies, or ambiguity)
  • Pause (business meaning is not yet stable)

If this decision cannot be made confidently, the SDD is not complete.

3. Ownership and Roles

  • Owner: Strategic Business Architect
  • Contributors: Business analysts, domain experts, workflow owners
  • Reviewers / Approvers: Business leadership accountable for domain correctness

There must be one accountable owner responsible for domain integrity.

4. Blank Artifact Template

⚠️ The SDD is authored in YAML and must follow the template exactly.

# ===============================================================
# STRATEGIC DOMAIN DESIGN SPEC (SDD)
# ===============================================================

departments:
  - name: "{DepartmentName}"
    description: "{What this department owns and is accountable for}"

    functional_groups:
      - name: "{FunctionalGroupName}"
        description: "{Purpose and responsibility of this FG}"
        metadata:
          roles:
            - "{RoleName}"
          stakeholders:
            - "{StakeholderName}"

        workflows:
          - name: "{WorkflowName}"
            description: "{Business outcome this workflow achieves}"
            triggers:
              - "{Business event or condition that starts the workflow}"
            preconditions:
              - "{Conditions required before workflow begins}"
            steps:
              - "{Business step 1}"
            postconditions:
              - "{What is true when the workflow ends}"
            success_metrics:
              - "{How business measures success}"
            business_records_created:
              - "{Business RecordName}"
            business_records_updated:
              - "{Business RecordName}"
            roles_involved:
              - "{RoleName}"

business_records:
  - name: "{Business RecordName}"
    description: "{Purpose and meaning of this artifact}"
    created_by_roles:
      - "{RoleName}"
    consumed_by_roles:
      - "{RoleName}"
    fields:
      - name: "{FieldName}"
        description: "{Meaning in business context}"
        required: true
    lifecycle:
      stages:
        - name: "{StageName}"
          description: "{Meaning}"
      transitions:
        - from: "{StageName}"
          to: "{StageName}"
          rules:
            - "{Strategic rule for transition}"

roles:
  - name: "{RoleName}"
    description: "{What this role does in workflows}"
    responsibilities:
      - "{Responsibility}"

business_rules:
  - key: "{SBR-XXX}"
    description: "{Rule governing how the business operates}"
    applies_to:
      - "{WorkflowName | Business RecordName | Lifecycle | FGName | DepartmentName}"

5. Required Inputs

All of the following are mandatory:

  • Project Initiative Package (PIP) - approved scope and outcomes
  • Product Requirements Document (PRD) - business meaning
  • Business Workflow Specification (BWS) - real-world workflows
  • Domain Parts List (DPL) - locked vocabulary

If any input is missing or unstable, the SDD must not proceed.

6. Input Acceptance Criteria

Before assembling the SDD, verify:

  • Outcomes are approved and locked
  • Business workflows reflect reality
  • Domain language is consistent across artifacts
  • No technical interpretation exists upstream

If business meaning is still debated, return to earlier artifacts.

7. Assumptions to Surface

Common assumptions at this stage include:

  • The domain is already understood
  • Similar workflows can be merged safely
  • Rules are implied rather than explicit
  • Business Records do not need lifecycle definition

These assumptions must be made explicit or rejected.

8. What Must NOT Appear in This Artifact

The SDD must not include:

  • Technical architecture or systems
  • APIs, schemas, or data models
  • Services, commands, or automation
  • Implementation constraints

If it describes how software works, it does not belong here.

9. Example - Completed Artifact (Excerpt)

departments:
  - name: "Customer Support"
    description: "Handles customer inquiries and issue resolution"
    functional_groups:
      - name: "Support Operations"
        description: "Manages case intake and resolution"
        workflows:
          - name: "Customer Identification"
            description: "Ensure a customer is identified before case resolution"
            triggers:
              - "Customer submits support request"
            steps:
              - "Collect identifying information"
              - "Confirm customer identity"
            postconditions:
              - "Customer identity confirmed"
            roles_involved:
              - "Support Agent"

10. Output Quality Checklist

  • [ ] All domain elements come from approved inputs
  • [ ] Organizational structure is clear
  • [ ] Workflows are complete and business-facing
  • [ ] Business Records and lifecycles are explicit
  • [ ] Strategic rules are stated

All items must pass to proceed.

11. Common Failure Modes

  • Turning SDD into pseudo-technical design
  • Inventing workflows or rules
  • Inconsistent terminology across sections
  • Omitting business record lifecycles

These indicate premature transition to TDD.

12. Review Questions

Reviewers should ask:

  • Could a new team understand the business from this alone?
  • Is responsibility and ownership unambiguous?
  • Are rules explicit rather than assumed?

If answers differ, revise the SDD.

13. What to Do If the Artifact Is Rejected

If the SDD is rejected:

  • Identify which upstream artifact is unstable
  • Correct language or structure at the source
  • Re-integrate only after clarity is restored

Do not patch the SDD directly.

14. Readiness Signal - Moving Forward

The SDD is ready when:

  • Business stakeholders agree it reflects reality
  • Domain language is stable
  • No technical questions are required to interpret it

Proceed to Stage 4 - Technical Domain Design (TDD).

15. What Invalidates This Artifact

The SDD must be revisited if:

  • Business structure changes
  • Rules or workflows are revised
  • Outcomes are modified

16. Downstream Dependencies

  • Next Stage: Technical Domain Design (TDD)

An unstable SDD guarantees unstable technical design.

Reminder: The SDD is the business contract. Everything technical is derived from it.