Domain-driven design et sémantique exécutable

Statut documentaire : architecture. Le manuscrit compagnon est un brouillon d'architecture, pas un contrat Runtime certifié.

Autorité sémantique avant partage du code

Le livre DDD déconseille l'ontologie d'entreprise universelle. Il distingue les niveaux fondation, partagé d'entreprise, domaine, bounded context et processus/application. Remonter un concept dans la hiérarchie uniquement si son sens reste vrai à ce niveau. Un champ partagé ou des écrans semblables ne prouvent pas un sens métier partagé.

Du vocabulaire à l'action exécutable

Pour chaque terme important, identifier son sens contextuel, son identité durable, son rôle, son état, ses invariants, ses actions et les événements émis. Un parcours utile est :

Verbe métier -> Action déclarée -> implémentation éventuelle -> publication éventuelle

Garder le verbe métier stable si l'implémentation évolue du déclaratif vers functionalP, une extension compilée ou un service distant.

Frontières et projections

Ventes, Stock et Comptabilité peuvent tous parler de Produit ou Commande tout en possédant des sens distincts. Context maps explicites, anti-corruption layers et langages publiés clarifient qui affirme quel fait et quand une projection est nécessaire. La coordination d'un processus long ne doit pas usurper l'autorité du contexte source.

Questions de validation

• Quel invariant est propre à ce bounded context ?
• Quel modèle ou quelle équipe possède la définition et ses évolutions ?
• Un concept envisagé comme partagé conserve-t-il réellement le même sens ?
• Comment tester changements de modèle versionnés et traductions entre contextes ?

Poursuivre

Domain Engineering · Méthodologie · Actions et événements · Exemple ERP

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