# 2.3 Establish the Domain Foundations

## Build Domain Foundations

{% hint style="warning" %}
Content work in progress
{% 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="/files/xF8CXivbfIOowUSEKGuY" 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>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://specs.govstack.global/implementation-playbook/1.0.0-rc/implementation/design-service/2-designing-the-future-service-to-be/2.3-establish-the-domain-foundations.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.