> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt. # 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](/reference/services/beto/contexts/party_governance/README.md) and [Project](/reference/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](/learn/tactical-ddd.md). Adapted from the [architecture reference](/learn/attribution.md), with Pharos examples.
Page source Source snapshot ยท Revision `f928834c8`.