# 2.3 Establish the Domain Foundations

## Build Domain Foundations

{% hint style="warning" %}
Content work in progress. We appreciate contributions. Contact us at <community@govstack.global>
{% endhint %}

Help teams build a shared understanding of the service domain before committing to detailed design or delivery.

The focus is on clarifying roles, responsibilities, concepts, and routines to create a stable foundation that user journeys, service blueprints, and technical decisions can build on.

[Read more about domain foundations](https://www.archi-lab.io/infopages/ddd/ddd-starter.html)

<details>

<summary><strong>How to do it</strong></summary>

Teams work through four simple steps: **Decompose, Strategise, Collect, and Organise**. All steps can be done on paper or a whiteboard.

<figure><img src="https://content.gitbook.com/content/YWL2CeaBio19sCOjxuQr/blobs/nTfNOWUTrT00SYWfZKlC/Domain%20foundations.png" alt=""><figcaption></figcaption></figure>

#### 1. Decompose the service <a href="#id-1.-decompose-the-service" id="id-1.-decompose-the-service"></a>

Break the service down into distinct areas of responsibility or concern.

A domain is a bounded area where:

* a specific role operates
* a set of routines or decisions happen
* particular rules or constraints apply

At a minimum, most services include:

* a user or citizen domain
* one or more government or processing domains

**Facilitator prompts**

* Who is involved in delivering or using this service?
* Where does responsibility clearly change hands?
* Which parts of the service operate under different rules or constraints?

#### 2. Strategise the domains <a href="#id-2.-strategise-the-domains" id="id-2.-strategise-the-domains"></a>

Discuss the importance and complexity of each domain.

Some domains:

* are core to delivering value
* carry higher risk or policy sensitivity
* require more flexibility or future change

Others may be:

* supporting or administrative
* more stable over time

This helps teams decide where to focus attention and avoid treating all parts of the service as equally complex.

**Facilitator prompts**

* Which domains are most critical to user outcomes?
* Which domains are hardest to change?
* Where do failures or delays usually occur?

#### 3. Collect domain knowledge <a href="#id-3.-collect-domain-knowledge" id="id-3.-collect-domain-knowledge"></a>

For each domain, collect the key information needed to understand how it works.

This may include:

* main roles and responsibilities
* typical routines or tasks
* decisions made and outcomes produced
* rules, policies, or constraints that apply

Use simple language and examples. Avoid technical detail at this stage.

This step often surfaces:

* different interpretations of the same terms
* gaps in understanding
* assumptions that need testing

#### 4. Organise and align <a href="#id-4.-organise-and-align" id="id-4.-organise-and-align"></a>

Bring the information together into a shared view of the domain foundations.

This may result in:

* a simple domain map
* a shared glossary or service dictionary
* notes on how responsibilities change in the future service

Focus on alignment rather than precision. The output should be good enough to support design, not a final model.

**Facilitator prompts**

* Do we agree on what these terms mean?
* Are responsibilities clear?
* What feels uncertain or contested?

</details>

<details>

<summary><strong>Outputs</strong></summary>

* [ ] A list of identified domains
* [ ] A description of key roles within each domain
* [ ] A summary of core routines or responsibilities per domain
* [ ] A shared glossary or service dictionary
* [ ] A list of assumptions, risks, or open questions
* [ ] Notes on how domains or responsibilities may change in the future service

</details>