Difficile de trouver par quel bout commencer. Sami Jaber a tenté d'expliquer DDD par opposition à l'approche SOA. C'est un pari intéressant quand on essaye de convertir des accros aux SOA, mais le soucis majeur est que DDD finalement, n'est pas technique. DDD est à mon sens avant tout une nouvelle manière de concevoir le développement d'une application d'entreprise.
Ce n'est pas une architecture binaire stipulant ou mettre tel ou tel bout, mais avant tout une manière de combler le gouffre qu'il existe entre le développement et le métier pour faire des applications qui répondent aux besoin tout en dépassant les attentes. C'est un complément parfait à une approche agile au développement.

Du coup, à se concentrer sur la technique, l'ami Sami passe à côté de l'intérêt de DDD, et en plus se mélange les pinceaux dans les concepts.
  • Une de ses plus grandes confusion je pense vient des services. Je pense qu'il n'a pas vu que même s'ils portent le même nom, les services de DDD et les services de SOA n'ont rien en commun. Il existe en fait 3 types de service définit par Evans: les services d'application (interface, export excel), les services d'infrastructure (envoi de mail) et les services du domaine qui répondent à un métier bien précis(transfert d'argent entre deux comptes par exemple). Un service du modèle n'est pas une couche à part, et à faire cette confusion, l'ami Sami a juste complètement perdu son public, au point qu'un auditeur a finir par faire la remarque que le métier avait l'air éclaté dans trop d'endroits. DDD c'est justement réunir tout le métier et toute la complexité en un seul endroit: le modèle du domaine. Pour organiser ce modèle, Evans fournit plusieurs éléments: les services, les aggregate root, les entities, les value objets, les repositories et les modules.
  • Une autre confusion vient de la différence justement entre aggregate root, entities et value object. Si on en croit Sami Jaber, tout ce qui est sous une racine d'agrégat est une value object. Faux. On peut trouver des entités sous des racines d'aggrégat, et d'ailleurs une racine d'aggrégat est une entité. La différence entre entité et value object est l'identité. Deux entités portant les mêmes valeurs peuvent être diffférentes, alors que deux value object, non.
  • Une autre confusion est de comparer les repositories aux DAL. Les repository ne sont pas une couche d'accès aux données, mais un entrepot, une collection d'entité. C'est entièrement métier, et fait donc partie intégrante du modèle également. TechniquementlL'IoC peut être ensuite utilisé pour ne pas coupler notre modèle avec la manière dont nous allons gérer ces entrepôts.


Dans une deuxième moitié de session, Sami Jaber a présenté une manière intéressante de tenter d'automatiser le binding entre les objets du modèle et la couche présentation. L'idée est de placer des attributs par exemple sur nos setter des objets du modèle, et on peut imaginer un framework de présentation capable de lire par réflexion ces attributs pour automatiquement générer les validateurs qui vont bien. L'idée est intéressante je trouve si elle est couplée avec un framework mvc standard sur lequel on puisse prendre la main pour faire des choses plus compliqués que des get/set. Je ne sais plus où est ce que je l'ai vu, mais je le répéte: il n'existe pas de simple application CRUD. Donc les idées qui permettent de faire du CRUD rapidement c'est intéressant, mais il ne fait jamais oublier que ça ne suffit jamais, et qu'il faut toujours prévoir un moyen propre et élégant de prendre la main. C'est ce que je reproche finalement à la plupart des outils RAD.