Orienté Objet

Quand on découvre le Domain-Driven Design, surtout à travers les livres récents, on commence souvent par enseigner le design stratégique, à savoir identifier le Domain et les Subdomains, et décomposer son application en Bounded Contexts. Seulement, la différence entre les deux est souvent mal compris (peut-être également mal expliquée ?). On parle souvent d’alignement et de microservices, on aime à penser qu’un Bounded Context est la matérialisation d’un Subdomain. La réalité est plus riche que ça. ...

Un bon moyen de saisir la notion de Bounded Context est de se projeter dans la vision orienté-objet qu’on se faisait d’un Domain Model à l’époque où l’OO n’était pas encore mature. Le nirvana du dev OO était la conception d’un modèle unifié et parfait. Un joli diagramme qui fait la jonction entre tous les éléments d’un domain sans aucune rature. Mais sur des systèmes larges et complexes, c’est impossible. ...

Si vous êtes familier avec le domain-driven design, vous avez certainement soupé du Invariant Métiers et de l’importance des Aggregates dans leur modélisation. Seulement, modéliser un invariant métier dans un aggregate n’est pas toujours simple. Invariant simple Prenons un exemple. Vous développez une application e-commerce classique comme celui d’Auchan et on vous demande de limiter le nombre de commande par produit à 3. En bon développeur, vous avez modélisé un Aggregate Order qui contient des LineItems correspondant aux différentes produits commandés. ...