https://www.developpez.net/forums/blogs/43007-ego/ Developpez.com, le Club des Développeurs et IT Pro fr Fri, 17 Apr 2026 05:36:07 GMT vBulletin 15 https://forum.developpez.be/images/misc/rss.jpg https://www.developpez.net/forums/blogs/43007-ego/ https://www.developpez.net/forums/blogs/43007-ego/b140/approche-services-applications-incompatible/ Sat, 10 Jan 2015 13:06:27 GMT Depuis toujours, euh enfin... Depuis toujours, euh enfin depuis que l’on fait des logiciels, on parle d’applications informatiques. Nos activités de conception et de développement mais aussi bien souvent nos organisations sont guidées par ce concept d’application. Il y a quelques années déjà est apparu le concept de SOA (Service Oriented Architecture) et toutes ses batteries de sous-concepts, middlewares et technologies d’échanges. Depuis peu la notion de micro-services est apparue avec ceci de particulier par rapport au SOA que l’on y aborde la notion de « taille » du service et d’unité de déploiement en production.
Pour simplifier, le SOA dit qu’il faut résonner par « services » offerts au sein d’un système d’information mais sans aborder la notion d’application, sans la remettre en cause en tout cas. Donc si vous avez une application, grosse ou petite, mais qu’elle offre clairement des « services » à son écosystème, et bien tout va bien, vous faites du SOA.
Avec l’approche micro-service, non seulement on met en avant les principes du SOA mais en plus on essaye de travailler sur la taille de ces services et sur la taille de l’unité de déploiement qui va contenir ces services. L’idée étant qu’en faisant des unités de déploiement les plus petites possible, les déploiements fréquents seront plus faciles. Vous serez plus « Agile » parce que « lancer des petits cailloux » c’est plus facile que « lancer un gros rocher ».

Bon, tout ça c’est bien gentil mais comme bien souvent en informatique, on lance des théories, au demeurant intéressantes pour faire avancer les idées, mais on sombre vite dans la technophilie. Car si vous avez suivi les débats sur le Web au sujet de ces approches SOA et micro-services, les discussions se raccrochent vite à des frameworks techniques et problématique de protocoles de communications et autres formats d’échange.
Or, le problème essentiel qui n’est toujours pas résolu, et qui probablement n’a pas de réponse absolue, peut être résumé comme suit :

• Quelle est la bonne la taille des services ?
• Quelle est la bonne taille d’un regroupement de services pour s’assurer d’une performance acceptable ?

Vous le savez sûrement, si on fait des services de taille très petite, on aura beaucoup de communication inter-services pour réaliser une tâche métier plus conséquente. Et qui dit pleins d’appels entre services dit problématique de performance. Si vos services sont dans des unités de déploiement distinctes, comme cela peut être préconisé par l’approche micro-services, vous aller vous retrouver en plus avec des communications inter-services non pas uniquement « en mémoire » mais via des interfaces « réseaux », via des protocoles sur HTTP par exemple et avec des problématiques de marshalling/unmarshalling en cascade.
Donc que l’on réfléchisse de manière théorique comme le propose SOA ou que l’on intègre en plus la notion de petites unités de déploiement en production comme l’ajoute l’approche micro-service, on voit bien que l’on ne peut pas rester sur une simple approche « service » et qu’il faut sérieusement penser au regroupement de ces services dans des unités de déploiement…pas trop petites non plus.

Eh bien vous savez quoi ? Cette unité de déploiement « pas trop petite » qui offre des services c’est notre bonne vieille application !
Donc retour à la case départ, une application offre des services, ça c’est acquis. Une application ne doit être ni trop grosse ni trop petite car sinon on a, soit des problèmes d’évolutivité, soit des problèmes de performance et de gestion de cohérence.

Et donc, quelle est la bonne taille d’une application ? Qu’est-ce qui pourrait nous aider à déterminer une taille « qui va bien » ?.

........le DDD bien sûr !!! ]]> ego https://www.developpez.net/forums/blogs/43007-ego/b140/approche-services-applications-incompatible/ https://www.developpez.net/forums/blogs/43007-ego/b125/ddd-j-aime/ Mon, 22 Dec 2014 15:46:01 GMT Un petit ressenti sur le... Un petit ressenti sur le Domain Driven Design après plusieurs années à regarder ce qui se dit...
Bon déjà, le concept j'aime bien et je défends cette idée que partir du modèle du domain est vraiment un point important pour faire de bonne application bien structurée, où on a bien partagé avec le métier et pour laquelle on a réussi à définir le bon niveau de service (api).

Mais alors, dans les discussions on sombre bien trop vite vers de l'implémentation et de la technicité. Et comme bien souvent dans ce genre de mouvement très en lien avec l'Agilité, on part dans des considérations de type management qui nous éloignent du sujet. De plus, sous prétexte de ne pas vouloir standardiser quoi que ce soit dans ce monde de l'agilité, on discute et on évite, par exemple, d'approfondir les sujets avec des notions et surtout concepts issues d'UML, pour ne prendre que cet exemple.

Bon alors qu'est ce que je propose, c'est bien de critiquer mais faut quand même proposer quelque chose......ouhai ça c'est sûr.

Bon déjà, les patterns c'est bien (Entity, aggregate, value object,...) mais revenons vers le métier, tout simplement. Dans un métier donné (un contexte), certains objets sont particuliers dans ce sens que le "client" ou le métier est capable de le connaître à partir d'une référence métier. Il ne s'agit pas de parler d'identité car ce terme est trop ambigue selon moi. Il fait trop référence à l'identité, l'id que l'on a quand on va parler de persistance.
Pour faire simple, un contrat est bien souvent connu à partir de son numéro, idem pour une commande pour laquelle le système créé un numéro de commande unique pour pouvoir suivire la dite commande. Ce numéro n'a rien d'un artifice technique, c'est bien une propriété métier de l'objet dont le format est connu par le client et/ou le métier. Rien à voir avec le "clé primaire" en base de donnée....d'où le fait que je n'aime pas que l'on parle d'identité.

Et donc oui, ces objets avec référence métier sont des Entités. Mais ce n'est pas un pattern magique que l'on applique, c'est juste la réalité, l'objet en question a été modélisé (on a fait une classe) et il a été marqué Entité, mais c'est tout.

Alors ensuite, si cet objet est constitué d'autres parties, notion d'aggrégation ou de composition en UML, alors oui, ses parties ne sont pas des Entités. Encore une fois, pas de pattern appliqué de manière spécifique mais juste de la modélisation standard avec les notions classiques d'UML. Ben ouhai en parlant UML, on n'a pas forcément besoin d'inventer de nouvelles notions...

Ensuite, j'aimerai parler des fameux contextes.
Ces contextes me paraissent un peu fumeux. Je veux dire que si dans un SI on a des contextes différents qui justifient des représentations différentes d'un même concept alors c'est que l'on a des contextes qui ne se parlent pas.
Dans le cas contraire, il me parait nécessaire de plutôt développer des principes d'urbanisation des données, je m'explique.

Dans un SI correctement urbanisé, un concept est sous la responsabilité d'un seul "système". Prenons un exemple simple avec la notion de Personne. Dans le contexte de ce SI, une personne comporte un certain nombre de propriétés dont le système responsable assurera la cohérence. Alors oui, d'autres systèmes dans le SI peuvent avoir besoin de cette personne et cet autre système pourra être tenté de dire, oui mais moi j'appelle le concept Personne plutôt avec le terme Titulaire car je gère des contrats pour lesquels la personne est titulaire.
Ok, ok, mais dans une approche "Urbanisation de données", il est préférable d'utiliser le notion de Rôle. C'est à dire que dans le système de gestion des contrats, on aura, non pas le concept Personne renommé en Titulaire, mais clairement la classe Titulaire en relation avec la class Personne. Cette dernière, sera "importée" depuis le système responsable de la Personne. Et la classe Titulaire pourra comporter les propriétés que la personne a lorsqu'elle joue le rôle de titulaire.

Avec cette approche globale, il n'y a pas vraiment de contexte mais simplement des responsabilités clairements définies au niveau du SI et des usages de concepts entre systèmes/application avec utilisation du principe de Rôle dès lors que le concept réutilisé a "besoin" d'être renommé, besoin entre guillements car vous l'avez compris, avec le pattern Rôle, il s'agit non pas d'appliquer un pattern technique mais bien de représenter la réalité, dans notre exemple une Personne existe bien en tant que telle mais joue parfois des rôles particuliers. Ce concept de rôle est facile à comprendre avec la notion de personne mais à l'usage, vous verrez qu'il s'applique à d'autres situtations. Et d'ailleurs, vous verrez que trouver un nom pour le rôle joué par le concept vous oblige à préciser le métier et donc à questionner vos collègues du métier afin qu'ils soient le plus précis possible (ex: un outil utilisé par qqun devient outil et usage, Personne qui dirige un projet devient Personne et Chef de projet, produit acheté au sein d'une commande devient Produit et Ligne de commande,...


Pour terminer mon petit billet, je dirai que le DDD c'est bien mais je préfère le GDD, Global Domain Design.

Bon si cela vous fait réagir, je peux développez un peu plus.... ]]> ego https://www.developpez.net/forums/blogs/43007-ego/b125/ddd-j-aime/