Domain-Driven Design : pourquoi le modèle universel n'existe pas

Exercice de modélisation informatique : si je vous demandais de modéliser une table, que feriez-vous ?

…

Votre premier réflexe devrait être de vous enquérir de la finalité. En effet, la modélisation ne sera pas la même selon que :

Dans ces 3 cas, vous ne recherchez pas les mêmes qualités, si bien que vous vous attendez à cocher des cases différentes sur votre site e-commerce préféré. Une bonne table, quand vous êtes chef du Kremlin, c'est au moins 6 mètres de long, tandis que le chirurgien s'intéressera plus au matériau (acier, fibre de carbone), au fait qu'elle soit réglable en hauteur et n'entrave pas les mouvements du personnel. C'est une évidence, mais vous avez en tête un modèle de table qui découle de l'usage que vous envisagez.

Plus généralement, quand vous poursuivez un objectif, vous construisez implicitement un modèle du monde qui sert cet objectif, et que cet objectif : si vous voulez faire le tour du Monde à la voile, une carte des courants marins vous sera plus utile qu'une carte des religions ou des minerais (en revanche, une carte topologique  pourrait vous aider).

Il n'y aurait d'ailleurs aucun sens à parler de la carte du monde : aucune carte ne saurait représenter le monde entier, dans toutes ses dimensions. La réalité est infinie, alors que la représentation que vous en ferez est nécessairement finie.

Qu'est-ce donc qu'un modèle, informatiquement parlant ? Un modèle est une abstraction, c'est-à-dire une représentation simplifiée de la réalité construite dans un but opérationnel précis.

Classiquement, c'est le moment où l'on mentionne ces deux citations :

Alfred et Georges disent en fait la même chose : un modèle représente une facette de la réalité, pas la réalité elle-même. Avant toute chose, un modèle fait donc l'impasse sur toutes les facettes de la réalité, sauf une. Quant à cette facette, elle-même est représentée de manière imparfaite : elle est peut-être simplifiée, incomplète ou carrément erronée. Et pourtant, ce modèle peut s'avérer utile pour atteindre votre objectif : une carte, à la bonne échelle, vous aidera même si elle n'est pas parfaitement à jour.

En matière de systèmes d'information, cela signifie qu'il n'y a pas de modèle unique, de modèle à tout faire, de modèle canonique. Une telle tentative reviendrait à mélanger des finalités différentes. Il y a un modèle par contexte, ce mot étant à comprendre au sens du Domain-driven design  (bounded context), parce qu'un contexte traduit justement une finalité opérationnelle. Ce que l'on veut, c'est distinguer les modèles afin de les laisser diverger, les spécialiser chacun pour un usage très précis.

Par exemple, votre système d'information ne saurait proposer une représentation unique d'un Produit, car les différentes directions de l'entreprise ne font pas du tout la même chose avec ce produit : l'une le conçoit, l'autre le fabrique, la troisième le stocke, une autre encore le commercialise et peut-être qu'une dernière le recycle.

S'il n'y a qu'une chose à retenir, la voici :

1 contexte <=> 1 modèle

Un modèle est donc une projection de la réalité sur un usage. Mais qu'est-ce, au juste, que la réalité ? Peut-on vraiment y accéder, ou n'accède-t-on pas qu'aux projections de cette dernière ? C'est, au fond, ce que suggérait déjà Platon dans l'Allégorie de la caverne  : les humains tournent le dos au Soleil et ne voient que les ombres du monde réel portées sur le fond de la caverne. Pour ces humains, les ombres sont le monde réel*.