Skip to content
EN FR

Module Development Method

Documentation status: guide — see Maturity and evidence.

Start from business facts, not screens

Collect the stable facts of the domain before designing pages or tables. Identify the things that have identity, the roles they can play, the relationships that matter, the events that occur, the constraints that must remain true, and the lifecycle changes that carry business meaning.

Classify concepts by ontology level

For each candidate concept, decide whether it belongs to the foundational, cross-domain, or sector level. If a concept is sector-specific, do not push it into a foundational package for convenience.

Build the conceptual model

Define:

  • concepts and identities;
  • roles and relation participants;
  • cardinalities and validity;
  • invariants and defaults;
  • temporal semantics;
  • classifications and extensibility points.

Use explicit relations when the connection has business meaning of its own.

Define lifecycle and domain events

Identify meaningful states and allowed transitions. Distinguish intentions from facts: actions request work; events record what occurred.

Published events should expose stable business semantics without leaking private aggregate structures.

Define aggregates and transaction boundaries

Choose boundaries according to invariants that must be protected atomically. Keep very large histories, projections, or independently evolving structures outside an aggregate when that improves scale without breaking domain consistency.

Project into implementation

Only after the conceptual model is stable should it be projected into model files, persistence facets, collections, actions, services, views, and SDK-facing capabilities.

Technical projections must preserve conceptual names and responsibilities. Storage and transport are implementation concerns, not sources of domain identity.

Verification and tests

Validate at several levels:

  1. semantic — are the concepts and boundaries correct?
  2. structural — are identifiers, relations, manifests, and dependencies coherent?
  3. runtime — does the model load and execute as intended?
  4. contract — do published services and bindings match their documented public signatures?
  5. regression — do representative business scenarios still preserve invariants after evolution?