# Strategic DDD: language and ownership

Domain-driven design connects software design to a shared understanding of the
business. Strategic design identifies the models a system needs, their boundaries
and their relationships. The purpose is to make business meaning explicit enough
that people can discuss and change the software coherently.

## Domain and language

A domain is the activity being modelled. Subdomains identify areas of that problem,
such as Project governance, support and workload execution. Core, supporting and
generic classifications depend on the organisation's strategy.

A ubiquitous language gives each model precise meanings. In Pharos, distinguish
a canonical Party, a provider account and a Project membership. A provider account
can exist while its association is retired; a Party can be authenticated while a
particular Project capability is unavailable.

## Bounded contexts

A bounded context defines where a model and its language apply. The same person
can appear in several models with different responsibilities.

| Context | Owned decisions |
| --- | --- |
| Party Governance | Canonical authentication identity and verified provider associations |
| Project | Canonical Project, source-managed metadata and complete memberships |
| Support | Customer linkage and support-ticket workflows |

Project resolves member references through Party Governance's published boundary.
A canonical identifier connects the models. Each context retains its own rules,
credentials and persistence authority.

## Context maps and translation

A context map records dependencies between models. A published language defines the
interchange vocabulary. An anti-corruption layer translates external terms into
the consuming model and protects its invariants.

```mermaid
flowchart LR
    AAI[Verified authentication evidence] --> Party[Party Governance]
    Waldur[Qualified Waldur source observation] --> Project[Project]
    Party -->|Published binding queries| Project
    Project -->|Canonical contracts| Consumers[Enrolled consumers]
```

This is a selected dependency map, rather than an activation diagram. Project's
Waldur adaptor maps supported source roles to canonical roles; unsupported roles
remain observations and grant no capability. This is a concrete translation rule.

A subdomain describes the problem, a bounded context delimits a model, and a service
is a deployment boundary. Beto hosts several contexts without combining their
aggregates or database ownership.

Read [Party Governance](../../../services/beto/contexts/party_governance/README.md)
and [Project](../../../services/beto/contexts/project/README.md). For each decision,
name its owner, the evidence it accepts and the contract a consumer can rely on.

Next: [Tactical DDD](tactical-ddd.md).

Adapted from the [architecture reference](attribution.md), with Pharos examples.