Comme je l'avais dit il y a pas mal de temps maintenant, Java est notre langage de choix pour développer notre belle application (nom de code, Tiron). Ceci dit, un langage c'est mignon, mais il nous faut choisir ensuite tout un tas de framework nous permettant de développer notre application de A à Z tout en nous permettant de nous concentrer sur le métier au maximum.

L'approche "par défaut" en java est la distribution à fond les ballons via entre autre, les EJB. Le problème avec ça, c'est que les EJB sont relativement complexe à utiliser, car ils répondent à un problème compliqué. Notre philosophie face à ça est de dire "mais pourquoi utiliser de la complexité dont nous n'avons pas besoin?". Apparemment, nous ne sommes pas les seuls à le penser, et c'est justement un des buts avoués de Spring, je site:

J2EE should be easier to use

En creusant un peu, on trouve également quelques assertions de plus qui correspondent tout à faire à notre approche:

OO design is more important than any implementation technology, such as J2EE.

Testability is essential, and a framework such as Spring should help make your code easier to test.

Bref, il y a de quoi séduire des développeurs comme nous, adeptes de modélisation plutôt que de technique lourde et souvent, inutile. Nous nous sommes donc jetés dans la brèche, et la partie rigolote de l'histoire, c'est que plus nous avancions, plus nous enlevions des responsabilités à Spring, au point ou finalement nous n'utilisons plus que Spring MVC. Pourquoi donc ce retour en arrière après tant d'enthousiasme? Encore une fois pour nos éternels raisons de "concentrons-nous sur le métier", et "rendons les choses explicites". Nous mettons en place une architecture qui tente de coller au mieux aux patterns de DDD.

Déjà premier constat, exit la couche de service qui fait les traitements sur des objets vide de sens. Pour le moment, le besoin d'une couche applicative ne s'étant pas fait sentir, nos controllers parlent directement au domaine, donc plus besoin d'injecter de service.

Ensuite, pour injecter l'implémentation des entrepôts, le ServiceLocator est définitivement à mon sens le moyen le plus simple et le plus explicite de le faire, donc exit la nécessité d'injection d'entrepôts dans les objets du domaine. Les controllers connaissant le domaine, ils ont connaissance aussi du ServiceLocator, donc pas besoin non plus d'injecter les entrepôts.

Les fonctionnalités de transaction? Nous utilisons le pattern SessionInView, donc nul besoin d'une gestion de transaction intégrée au domaine pour le moment.

Bref, en nous posant la question à chaque fois de savoir ce dont nous avions réellement besoin, même Spring et son aveux de simplicité semblait paradoxalement trop complexe.

Ce n'est pas la première fois que je me retrouve face à face avec un framework de container, et à chaque fois je me suis retrouvé finalement à le cantonner à faire bien peu de chose car je me suis rendu compte que j'avais toujours une solution élégante côté code. Peut-être que je n'ai pas eu l'occasion de travailler avec ces technos sur un assez gros projet, mais globalement mon ressenti est plutôt que c'est à la mode de faire le moins de code possible et de s'appuyer intensivement sur des fichiers de configuration/xml whatever. Personnellement je favorise toujours une solution via le code, pour la simple et bonne raison qu'il est compilé, testable, explicite et refactorisable beaucoup plus facilement en cas de changement. Si vous faites un changement x ou y dans votre application qui est censé engendré une modification dans un de vos fichiers de configuration,il y a de fortes chances que vous ne vous aperceviez du bug que des mois après, en production, car aucune test unitaire, aucune compilation ou aucune refactoring n'aura été capable de détecter cette dépendance entre la modification et la configuration.

La deuxième remarque que je ferai est finalement que dès qu'on parle d'inversion de contrôle, automatiquement tout le monde pense à de l'injection, alors qu'il existe d'autres manières de faire; et que même pour faire de l'injection, un framework n'est pas nécessairement utile. L'emploi d'un framework de container ne devrait pas être aussi systématique. Comme d'habitude, c'est Fowler qui en parle le mieux.

Bref, désolé pour ce billet un peu chaotique, il est de la grande série "j'écris comme ça vient, fautes comprises", et je me suis un peu éloigné du Projet pour revenir sur des considérations plus générales.