Skip to content
EN FR

Domain-driven design with executable semantics

Documentation status: architecture. The companion manuscript is an architecture draft, not a certified Runtime contract.

Semantic authority before code sharing

The DDD book argues against one universal enterprise ontology. It distinguishes foundation, enterprise-shared, domain, bounded-context and process/application levels. Promote a concept upward only when its meaning remains true there. A shared field or duplicated screen is not proof of shared business semantics.

From vocabulary to executable action

For each significant term, identify bounded-context meaning, durable identity, role, state, invariant, action and emitted event. A practical flow is:

Business verb -> declared Action -> optional implementation -> optional publication

Keep the business verb stable if its implementation moves from declarative behavior to functionalP, a compiled extension or a remote service.

Boundaries and projections

Sales, Inventory and Accounting may all refer to a Product or Order while owning different meanings. Explicit context maps, anti-corruption layers and published languages clarify who asserts which fact and where a projection is needed. Long-running process coordination must not impersonate the source context.

Validation questions

  • What invariant is local to this bounded context?
  • Which model or team owns the definition and its evolution?
  • Is a proposed shared concept semantically invariant across contexts?
  • How are versioned model changes and cross-context translations tested?

Continue

Domain Engineering · Methodology · Actions and events · ERP example

LaTeX sources: Domain-Driven Design with logiCells/ontology-levels-and-semantic-authority.tex, bounded-contexts-and-executable-language.tex, context-maps-and-semantic-projections.tex.