Logique du domaine

Dans un bounded context, les règles métier ont besoin d’un lieu. Cette partie en propose deux. Chaque bounded context choisit le sien, et le déclare une fois (CTX-14) :

Style	Pour	Forme
Transaction scripts	Les subdomains supporting et generic, où la logique est mince	Une procédure par use case : charger, vérifier, écrire, répondre, dans une transaction
Modèle tactique	Les subdomains core, où les règles sont riches et changent souvent	Aggregates, entities, value objects et domain events gardent les invariants ; les repositories les chargent et les enregistrent

Une règle propre à un seul style porte son badge. Les autres règles valent pour les deux. Pour décider, voir choisir un style.

• Transaction script la règle ne vaut que pour les transaction scripts
• Tactique la règle ne vaut que pour le modèle tactique
• Les deux styles la règle vaut pour les deux styles

Transaction scripts

TXS8 règlesTransaction scriptsUne procédure par use case, dans une transaction, pour les bounded contexts supporting et generic.Voir les règles →EVT7 règlesDomain eventsDes faits métier, nés dans le modèle et nommés dans le langage.Voir les règles →

Modèle tactique

AGG16 règlesAggregatesDe petites frontières de cohérence autour de vrais invariants.Voir les règles →ENT17 règlesEntitiesUne identité stable et des méthodes métier nommées.Voir les règles →VO11 règlesValue objectsDes valeurs immuables qui portent leur propre logique.Voir les règles →EVT7 règlesDomain eventsDes faits métier, nés dans le modèle et nommés dans le langage.Voir les règles →REP16 règlesRepositoriesDes aggregates entiers, écrits dans la transaction du use case.Voir les règles →FAC4 règlesFactoriesUne création maîtrisée, nommée dans le langage métier.Voir les règles →SRV8 règlesDomain servicesCe qui n’appartient à aucun objet : sans état, nommé dans le langage métier.Voir les règles →