Commentaires

Envoyé par bruneltouopi

L'approche SOA ou par micro service franchement dépend du contexte de l'application.
En plus il y'a des problématiques et des types de solutions qui imposerait de travailler avec l'un ou l'autre.
Donc chacun a des avantages et inconvénients.Le tout est de savoir si on répond à 90% au besoin du client,si le coût de maintenance ou de refractoring n'a pas un très gros impact,si bien on contrôle mieux les procédures de déploiements.

Comme je l'ai dit, le réel problème reste à ce jour la performance et la cohésion. Des choix de ce type d'approche se font quand même de manière globale dans un SI.
A trop découper on découpe mal et la gestion des petits "bouts" devient un cauchemar, engendre des problèmes de performance et de gestion de cohérence. Car on en vient à dupliquer l'information dans les différents "bouts" (composants).

Il faut donc trouver un moyen pour faire des composants ni trop petits ni trop gros.

L'approche SOA ou par micro service franchement dépend du contexte de l'application.
En plus il y'a des problématiques et des types de solutions qui imposerait de travailler avec l'un ou l'autre.
Donc chacun a des avantages et inconvénients.Le tout est de savoir si on répond à 90% au besoin du client,si le coût de maintenance ou de refractoring n'a pas un très gros impact,si bien on contrôle mieux les procédures de déploiements.

Envoyé par ego

Merci pour ton retour.
Bien sûr que l'on a des truc comme les esb ou autre mais he voulais mettre l'accent sur le "temps" que la communication da mettre. En mémoire ça reste toujours plus rapide.

L'avantage d'un activeMQ c'est qu'il est très léger et on peut donc avoir 1 activeMQ en local par service.
Alors qu'un ESB est souvent plus lourd et est placé sur une machine dédié ce qui fait qu'on ajoute une couche de protocole réseau qui alourdi les communications entre service.

Merci pour ton retour.
Bien sûr que l'on a des truc comme les esb ou autre mais he voulais mettre l'accent sur le "temps" que la communication da mettre. En mémoire ça reste toujours plus rapide.

Bonjour,

Je me permet de faire quelques commentaires par rapport à ce que tu dis.

Vous serez plus « Agile » parce que « lancer des petits cailloux » c’est plus facile que « lancer un gros rocher ».

Il y a aussi une phrase que j'aime beaucoup :

• Ce que vous trouvez dur, fait le souvent.

On dit cela en général, pour les merges pour git, mais aussi pour les mises en productions.
L'idée étant que la répétition de la tâche, la rends moins lourde.

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.

Pour le coup, il existe des outils qui gère cette partie comme ActiveMQ pour les JMS (Java Message Service). L'un des avantage principaux que j'y vois. C'est qu'un service non démarré aura l'ensemble des message qui lui sont destiné stocké par ActiveMQ et une fois le service "en service" celui-ci va dépiler les messages.
Ce qui est relativement pratique pour avoir une continuité pour les autres applications.

Eh bien vous savez quoi ? Cette unité de déploiement « pas trop petite » qui offre des services c’est notre bonne vieille application !

Cela est plus dû à une volonté des personnes à tout regroupé dans une application "qui fait tout".
A noter que cela n'est pas totalement idiot dans bien des cas. En général, cela permet de formaliser le métier pour l'ensemble des acteurs, qu'ils en ai la même approche. Ce qui est souvent le plus important.

........le DDD bien sûr !!!

Le DDD n'est pas magique. Il est évident que le découpage des services va dépendre du métier. Cependant, savoir-faire un découpage à partir d'un métier reste encore un travail d'expert du métier. C'est savoir ce qui est lié et ce qui ne l'est pas. J'ai déjà vu des personnes ne connaissant pas le métier, faire une réunion "DDD" avec les experts métier et décider de l'architecture juste après. Ca fait avancé le projet, mais pas sûr qu'en quelques réunions ces personnes ai réellement saisit toutes les interactions entre chacune de ces parties. Ce qui peu amener à des usines à gaz, qui ne serai pas arriver en gérant un problème à la fois. Ce qu'on réalisait bien plus souvent avec "notre bonne vieille application".

Cordialement,
Patrick Kolodziejczyk.

source :
http://en.wikipedia.org/wiki/Java_Message_Service
http://activemq.apache.org/jms.html

Je suis d'accord sur la notion d'identité qui n'est pas un id "base de données". Je n'aime pas l'usage de ce terme identité car ça peut vite être un ID technique mais ok, ce n'est pas ce qui est dit à la base dans DDD.
Personnellement, pour ne pas qu'il y ait d'ambiguité, je préfére parler de "référence métier". Car cela permet de montrer que cette "référence métier" n'est pas un artifice technique mais bien une propriété qui existe d'un point de vue métier mais qui a une valeur particulière.

Pour l'histoire d'UML, ce qui me gène dans les discours classiques c'est qu'on le voit trop comme un simple langage. Alors oui c'est un langage et que l'on peut l'utiliser de manières différentes mais il y a quand même des éléments sémantiques forts (généralisation, agrégation, composition). Donc quand on parle de modélisation, il me semble que l'on aurait intérêt à s'appuyer sur ces éléments sémantiques pour illustrer ce que l'on veut dire.

Pour revenir sur la notion de Contexte, effectivement, on peut avoir 2 contextes qui utilisent le même mot pour des concepts différents. Si ces 2 contextes "ne se parlent pas" ce n'est pas grave. Par contre s'ils se parlent, là c'est grave. Et je ne suis pas d'avis de systèmatiquement conserver le même terme.
Pour te donner un exemple réel dans le SI de ma boite. Dans un contexte de gestion des clients, on a le concept de prospect et de client. Dans un contexte de type contractualisation, on a le concept de client du contrat aussi.
Au départ ça peut rester comme cela en disant que l'on a 2 contextes et donc on a le droit d'avoir le même terme "client". Ben en fait ce n'est pas sémantiquement juste, même si dans le langage courant les gens du métier peuvent être aménés à parler comme cela.
Dans la réalité on a maintenant, après réflexion, la notion de Personne, la notion de Client, la notion de Prospect et la notion de Titulaire. Un même objet Personne est dans le premier contexte un "Client" et dans le second un "Titulaire".
Un Client est une Personne et un Titulaire est une Personne. Pas d'héritage ici mais une relation d'association de type "Rôle" (ça c'est une concept "à nous", pas UML) entre Personne et Client et entre Personne et Titulaire. Les classes Client et Titulaire sont des rôles (Classes stéréotypées "Rôle") joués par la classe "Personne".

Bref, ce que je veux dire c'est qu'il est important de creuser la sémantique quand on fait de la modélisation et ne pas s'arrêter à "j'ai 2 contextes" donc je peux garde le même mot pour 2 concepts différents. Surtout que quand on a ce cas de figure, il est possible (probable ?) que l'un des concept soit un rôle joué par l'autre.......et la recherche du terme adéquate pour ce rôle peut être bénéfique à la compréhension du métier.

Hello,

Je ne sais pas si tu as lu le bouquin Domain Driven Design ou sa version Quickly, mais je ne reconnais pas trop DDD dans la description que tu en fais. J'ai l'impression que c'est plus une pratique superficielle de DDD ou des stéréotypes qui ont été déformés au fil des conversations.

La notion d'identité n'est justement pas liée à un identifiant en base, c'est juste une donnée qui permet de suivre une entité pendant le cours de sa vie et de la retrouver. Ca peut être n'importe quoi - simple entier, email, plaque d'immatriculation, n° INSEE, séquence ADN, etc. Il faut l'entendre au sens "identification", "identitaire", "identique" (qu'est-ce qui fait que deux choses sont les mêmes ou différentes), ce n'est pas forcément un ID. Et le terme "numéro" ne me parait pas satisfaisant dans tous les cas non plus.

UML permet d'exprimer des modèles, pour communiquer entre développeurs et/ou analystes, concevoir, éventuellement générer du code ou de la documentation. UML est 100% compatible avec DDD, d'ailleurs dans le bouquin, Eric Evans indique que le support du modèle du domaine importe peu, ça peut être une illustration dessinée sur un bout de nappe et être tout aussi efficace. Du coup, j'ai du mal à voir ce que représente la "modélisation standard avec les notions classiques d'UML", puisqu'UML est juste un outil, un langage dont on peut se servir de 1000 manières...

La notion de Rôle en urbanisation est intéressante. Je pense qu'on n'est pas si éloigné de DDD, l'équivalent d'un Système étant un Contexte. Une différence majeure avec ce que tu décris cependant : en DDD, 2 contextes utilisent souvent les mêmes noms de classes, ils permettent de mieux gérer la polysémie de certains termes fonctionnels - c'est à dire précisément lorsque deux experts métier utilisent le même mot pour désigner deux réalités différentes. Un Produit dans le contexte Catalogue et un Produit dans le contexte Approvisionnement sont deux choses séparées, pourtant, difficile de les appeler autrement.