Skip to content

Step 9 - Domain Parts List (DPL)

Purpose

Extract and catalogue the business domain elements required to deliver a single approved initiative.

This step exists to identify what parts of the business domain are involved, without designing solutions, defining integrations, or making technical decisions.

The Domain Parts List (DPL) creates a controlled inventory of domain elements that will later be structured and related during Strategic Domain Design.

When To Run This Step

This step is executed by a person after the core Stage 3 business artifacts are complete.

Run this step when:

  • An approved Project Initiative Package (PIP) exists
  • A Product Requirements Document (PRD) has been completed for the selected Outcome
  • A Business Workflow Specification (BWS) has been completed and validated
  • The team is ready to identify domain scope for this initiative

This step must not run if:

  • Any of the PIP, PRD, or BWS is missing or incomplete
  • Business workflows are still changing
  • The team is attempting to design models, schemas, or system boundaries

Inputs (Required)

  • Approved Project Initiative Package (PIP)
  • Approved Product Requirements Document (PRD)
  • Approved Business Workflow Specification (BWS)

Prompt to Run

  • Prompt Name: Domain Parts List (DPL) Extractor
  • Prompt Version: v1.0
  • Prompt Location: DPL Generator

Instruction: Run the DPL prompt using the PIP, PRD, and BWS as inputs.

Extract and classify domain elements exactly as they appear in the approved documents. Do not invent, merge, or redesign domain concepts.

Outputs (Produced)

The step produces a Domain Parts List (DPL) containing a classified inventory of business domain elements, including:

  • Entities
  • Operations
  • Roles and functional ownership
  • Business rules and constraints
  • Permissions
  • Events and states
  • Outcomes
  • Business inputs and outputs
  • Triggers and exceptions

The output must strictly follow the DPL template.

Artifact Storage

Store the DPL in the predefined system of record selected during setup.

  • One DPL per initiative
  • One primary storage location only
  • The artifact must be referenceable
  • Ownership must be clear

Validation Rules

The DPL is valid only if:

  • All elements are derived directly from the PIP, PRD, or BWS
  • Each item is classified using the DPL Dictionary definitions
  • No technical design, data modeling, or integration logic is included
  • No domain consolidation or normalization is performed
  • Missing information is explicitly marked as TBD

The DPL is invalid if it:

  • Introduces new domain concepts not present in source artifacts
  • Proposes relationships, structures, or architectures
  • Reinterprets business intent
  • Blends multiple initiatives into a shared domain view

Invalid DPLs must be corrected before proceeding.

Decision Gate

Question: Is the full business domain scope for this initiative identified and classified?

Outcomes:

  • Yes: Proceed to domain structuring and Strategic Domain Design
  • No: Clarify missing elements and update the DPL

No other outcomes are allowed.

Failure Modes & Anti-Patterns

  • Treating the DPL as a design or modeling exercise
  • Inventing domain elements to "fill gaps"
  • Normalizing or consolidating domain concepts prematurely
  • Mixing technical terminology into business classifications
  • Allowing scope creep beyond the approved initiative

If this step is rushed or polluted with design thinking, downstream domain models will be unstable.

Traceability

  • Previous: Stage 3 — Business Workflow Specification (BWS)
  • Next: Stage 3 — Strategic Domain Design
  • Consumes: PIP, PRD, BWS
  • Produces: Domain Parts List (DPL)

Status

  • Maturity: Stable
  • Enforced by Tooling: Planned