Skip to content

Domain Parts List (DPL)

Stage: Stage 3 - Strategic Domain Design

Artifact Code: DPL

1. Purpose

The Domain Parts List (DPL) exists to extract and lock the business vocabulary required for this initiative.

It identifies what exists in the domain - entities, roles, rules, events, states, and boundaries - without describing structure, relationships, or implementation.

The DPL is a classification artifact, not a model.

2. Decision This Artifact Supports

Decision: Is the domain vocabulary complete, consistent, and stable enough to integrate into the Strategic Domain Design?

Possible outcomes:

  • Accept DPL and proceed to SDD Integration
  • Revise DPL (missing, ambiguous, or conflicting parts)
  • Pause (business language is not yet stable)

If the language is still shifting, the DPL is not complete.

3. Ownership and Roles

  • Owner: Domain Analyst / Business Analyst
  • Contributors: Domain experts, workflow owners
  • Reviewers / Approvers: Stakeholders responsible for business language

There must be one accountable owner responsible for vocabulary accuracy.

4. Blank Artifact Template

# Domain Parts List (DPL)

## Entities
- {Entity 1}
- {Entity 2}

## Operations
- {Operation 1}
- {Operation 2}

## Roles
- {Role 1}
- {Role 2}

## Functional Group
- {FG Name}

## Business Rules
- {Rule 1}
- {Rule 2}

## Constraints
- {Constraint 1}
- {Constraint 2}

## Permissions
- {Permission 1}
- {Permission 2}

## Events
- {Event 1}
- {Event 2}

## States
- {State 1}
- {State 2}

## Outcomes
- {Outcome 1}
- {Outcome 2}

## Inputs
- {Input Artifact 1}
- {Input Artifact 2}

## Outputs
- {Output Artifact 1}
- {Output Artifact 2}

## Triggers
- {Trigger 1}
- {Trigger 2}

## Exceptions
- {Exception 1}
- {Exception 2}

5. Required Inputs

  • Project Initiative Package (PIP) - approved outcomes
  • Product Requirements Document (PRD) - business rules and intent
  • Business Workflow Specification (BWS) - actions, decisions, exceptions

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

6. Input Acceptance Criteria

Before creating a DPL, verify:

  • Outcomes are locked and approved
  • Business workflows reflect reality
  • Requirements are business-facing and unambiguous

If business language is still changing, return to earlier artifacts.

7. Assumptions to Surface

Common assumptions at this stage include:

  • Everyone agrees on terminology
  • Similar words mean the same thing
  • Roles and entities are obvious
  • States do not need naming

These assumptions must be challenged explicitly.

8. What Must NOT Appear in This Artifact

The DPL must not include:

  • Technical concepts or system components
  • Data models or schemas
  • Relationships or hierarchies
  • Process flow or sequencing

If it describes structure or behavior, it does not belong here.

9. Example - Completed Artifact

# Domain Parts List (DPL)

## Entities
- Customer
- Support Case

## Operations
- Identify customer
- Resolve support case

## Roles
- Support Agent
- Support Team Lead

## Functional Group
- Customer Support

## Business Rules
- A support case must have an identified customer

## Constraints
- Customer identification must comply with privacy policy

## Permissions
- Support Agents may identify customers

## Events
- Support request received

## States
- Case opened
- Case resolved

## Outcomes
- Customer is identified
- Support case is resolved

## Inputs
- Support request

## Outputs
- Confirmed customer identity

## Triggers
- Customer submits support request

## Exceptions
- Customer cannot be identified

10. Output Quality Checklist

  • [ ] All domain terms come from approved artifacts
  • [ ] Language is consistent and unambiguous
  • [ ] No technical or design terms appear
  • [ ] Each section is meaningfully populated

All items must pass to proceed.

11. Common Failure Modes

  • Mixing design concepts with domain language
  • Inventing new terms during listing
  • Omitting states or events
  • Using inconsistent terminology

These indicate unstable domain language.

12. Review Questions

Reviewers should ask:

  • Would business stakeholders recognize these terms?
  • Are any terms overloaded or ambiguous?
  • Is anything missing that appears elsewhere?

If answers differ, revise the DPL.

13. What to Do If the Artifact Is Rejected

If the DPL is rejected:

  • Reconcile terminology across artifacts
  • Clarify ambiguous terms with stakeholders
  • Remove invented or speculative items

Do not proceed until language stabilizes.

14. Readiness Signal - Moving Forward

The DPL is ready when:

  • Business vocabulary is stable
  • Terms are used consistently across artifacts
  • Stakeholders agree on meaning

Proceed to Strategic Domain Design (SDD) Integration.

15. What Invalidates This Artifact

The DPL must be revisited if:

  • Business terminology changes
  • Outcomes are modified
  • Workflows are updated

16. Downstream Dependencies

  • Next Artifact: Strategic Domain Design (SDD)

Unstable domain language guarantees unstable domain models.

Reminder: The DPL locks language - not structure.