---
name: model-domain-behaviour
description: Discover and design a new domain model around business decisions, rules, and outcomes before defining entities, APIs, or database structures. Use when starting a feature, service, bounded context, aggregate, or workflow from scratch and turning business requirements into executable domain behaviour.
---

# Model Domain Behaviour

## Discover the domain

1. Define the business capability and the outcome it must enable.
2. Collect concrete examples of successful, rejected, exceptional, and boundary scenarios.
3. Identify the actors and name their intentions as commands in the domain language.
4. Name successful outcomes as past-tense facts.
5. Record the information and rules needed at each decision point.
6. Mark uncertain terminology and resolve it with domain experts instead of inventing precision.

Treat proposed screens, API contracts, and database schemas as constraints or evidence, not as the starting model.

## Assign behaviour

- Group rules that must be evaluated consistently for one business decision.
- Give the responsible object the state it needs to make that decision.
- Expose intention-revealing operations such as `Confirm`, `Cancel`, or `Reschedule`.
- Introduce value objects for concepts with intrinsic rules, units, formats, or cohesive values.
- Make invalid transitions explicit domain outcomes.
- Use a domain service only when important behaviour does not naturally belong to one entity or value object.
- Use policies or process managers for workflows spanning independent consistency boundaries.

Keep transport, persistence, UI flow, and technical orchestration outside the domain model.

## Shape the model through scenarios

For each scenario, trace:

1. the command and actor;
2. the current domain state;
3. the decision rules;
4. the success or rejection outcome;
5. the resulting state or domain events;
6. any policy or external reaction.

Implement only the state and abstractions required by known behaviour. Delay speculative entity hierarchies, repositories, and generic frameworks until scenarios demonstrate a need.

## Validate the design

Express tests in the ubiquitous language and focus them on decisions and outcomes. Confirm that the model explains why change occurs, protects invariants at the point of decision, and supports all collected scenarios without exposing public mutation.

## Deliver

Provide the glossary, scenarios, commands, decisions, invariants, entities, value objects, domain services, outcomes or events, consistency boundaries, tests, and unresolved domain questions.