Je me permet de revenir sur l’approche que nous avons présentée, car elle est fondamentale pour comprendre notre démarche. Ok, notre produit est jeune et a encore des défauts, et je souhaiterais insister sur l’esprit de l’approche, et la vision de l’Architecture que nous proposons.

- Il est difficile de prévoir, un SI est issu d’un travail intellectuel, qui se nourrit lui-même de l’usage de l’existant, et qui est en constante évolution.
Aujourd’hui, le SI souffre d’une complexité importante et l’essentiel des difficultés porte:

sur la maîtrise des coûts et des délais pour le développement et la maintenance d’un projet.
l’adéquation entre les attentes et la réalisation.

- Certains éléments techniques sont connus d’avance, on sait par exemple:

qu’il y aura une base de données relationnelles qu’il faudra lire et écrire des données relationnelles.
qu’il y aura des écrans avec des contrôles dans lesquels il faudra afficher ces mêmes données relationnelles (ou d’autres, qui seraient calculées, mais qui seront toujours relationnelles).
qu’il y aura des traitements à appeler à partir de l’interface utilisateur; il peut s’agir de calculs, de validation, de processus, ou de transfert d’informations.
qu’il y aura toujours un tas de services techniques connus d’avance (sécurité, trace, bouchons, log, traitements d’erreurs, distribution, …)

- De notre point de vue, une partie importante de cette complexité et de ces difficultés est lié au mélange qui est fait entre le code technique (qui effectue des taches sans grande valeur ajoutée) et les éléments métiers, qui sont fluctuant, et de nature à évoluer librement avec le temps et les usages.

- Notre approche consiste donc à isoler ces invariants techniques pour:

ne les coder qu’une seule fois (approche DRY).
séparer plus clairement les éléments métiers des éléments techniques.
proposer une Architecture qui permette de bénéficier de ces éléments techniques, sans avoir à les écrire ou les modifier, quel que soit le domaine métier concerné.
faire intervenir les éléments métiers de la façon la plus light et la moins intrusive possible car ceux-ci vont bouger. Une bonne façon de faire pour répondre à ce besoin est de faire du Déclaratif plutôt que de l’Impératif.

- D’un point de vue des données: on est dans un schéma de données relationnelles, qui exprime un besoin fonctionnel. Les notions d’Entités et de Relations sont relativement faciles à comprendre et à modéliser. Notre travail consiste donc à permettre la modélisation de ces données, de façon la plus souple et la plus dynamique possible, parce que la nature de ces informations va évoluer avec le temps, et qu’il faudra être capable d’être réactif à ces changements. Ce point de vue privilégie naturellement l’usage du DataSet vs Modélisation Objet, qui nécessite de connaître beaucoup de choses d’avance, et qui s’exprime par du code, coûteux à concevoir, écrire et maintenir. Nous ne décrions pas l’objet, car nous l’utilisons tous les jours quand nous savons que l’objet ne va pas évoluer dans le temps. Par contre, dès que nous avons à faire des choses que nous ne connaissons pas d’avance, l’objet est mal adapté. Le DSL est là pour apporter une représentation graphique du DataSet, toujours plus conviviale et plus lisible que du code ou du XML.

- D’un point de vue des traitements: on est dans une logique de Services Stateless, .Net apporte tous les éléments pour les implémenter. Les Services techniques centraux sont implémentés une seule fois, et un point de passage unique permet de garantir l’interception de tous les traitements par ces Services techniques. C’est la configuration (tardive !) qui définiera comment cette interception est faite.

- D’un point de vue IHM, les contrôles sont développés avec le designer de Visual Studio. Nous pensons qu’il est important de séparer les couches, et notamment l’IHM, qu’il convient de laisser indépendante du reste. C’est pourquoi notre architecture permet de réaliser un DataBinding ou un CommandBinding déclaratif sans polluer l’IHM avec du code.

Voilà, une fois qu’on a présenté l’approche, on a fait une démo de notre (jeune !) produit qui permet de s’approprier facilement l’architecture proposée.

On a effectivement déplacé un certain nombre de problèmes:
- on a plus de clics qu’avant (mais on a moins de frappe de touches ) Ce clic remplace une tâche de codage sans aucune valeur ajoutée; du coup, sa réalisation et sa maintenance sont beaucoup plus facile.

- à propos du débat sur la nécessité d’exécuter les applications pour vérifier qu’il n’y a pas d’erreurs, les services sont testables de façon tout à fait classique. Pour ce qui est de tester la configuration de l’IHM, elle est testable immédiatement, et il n’y a pas de test à écrire, il suffit de lancer l’application. Et plus l’erreur est détectée tôt, et moins elle est concernée par du code écrit, et plus elle est facile à corriger (là encore, quelques clics seront préférable à modifier du code).

- le déplacement de la complexité fonctionnelle du code impératif vers des éléments déclaratifs configurés pose effectivement quelques questions:
le nommage des éléments est fondamental pour la bonne compréhension des choses.
l’évolution dans le temps et la lisibilité des versions des éléments configurés: je suis d’accord que le XML est verbeux, et pas forcément facile à lire. Mais, l’usage de quelques clics pour configurer fait que la configuration est faite rapidement, et que l’on ne se trouvera pas dans une situation conflictuelle de configuration, contrairement à l’écriture de code, qui nécessite de réfléchir, concevoir, écrire et compiler. Je ne dis pas que le problème ne se posera pas, mais il sera beaucoup moins crucial. A nous maintenant d’imaginer comment compléter les outils pour le proposer de manière pratique.

Nous avons toutefois fait très attention à maintenir l’intégration possible avec du code .Net dans tous les endroits de notre architecture. Il est facile d’intégrer du code spécifique pour palier aux manques, car nous sommes sur un terrain qui nécessite une couverture fonctionnelle immense, que nous n’avons pas la prétention d’avoir couverte aujourd’hui.

Nous sommes conscient de bousculer pas mal d’idées reçues avec notre approche. Le fait de ne pas avoir typé les échanges de données par des classes mais par un schéma relationnel, peut poser un problème à un développeur, mais sûrement pas à un fonctionnel. Nous sommes sur le terrain du Customer Satisfaction Business, nous essayons de ne pas perdre de vue cet objectif ambitieux.

Je me permet enfin de remettre le lien vers l’article précis du résumé de notre blog.

Un grand merci également à Nicolas et Frédéric qui ont su présenter leur produit avec passion malgré les questions et remarques permanentes de l’assemblée. Alt.net n’était probablement pas l’audience la plus « naturellement acquise » à leur approche, mais c’est ce qui a rendu le débat passionnant ! Je leur souhaite ne tout cas bon courage pour le futur !