Discussion :

[sauzanne]

Bonjour,

J'aimerais avoir votre avis sur le fait qu'un service métier puisse appeler un autre service métier. Quels sont les avantages / inconvénients de l'autoriser ou de l'interdire ?

Merci de vos avis éclairés sur la question

[souviron34]

Bonjour et bienvenue

J'aimerais avoir votre avis sur le fait qu'un service métier puisse appeler un autre service métier. Quels sont les avantages / inconvénients de l'autoriser ou de l'interdire ?

euh.... En quoi serait-ce à toi / à l'urbaniste () d'interdire ou d'autoriser la communication entre 2 services métiers ???

Cela fait partie de la définition de la fonctionalité du métier...

Ou alors nous n'avons pas les mêmes définitions de ce qu'est un métier ou un service métier...

[sauzanne]

Bonjour et bienvenue





euh.... En quoi serait-ce à toi / à l'urbaniste () d'interdire ou d'autoriser la communication entre 2 services métiers ???

Cela fait partie de la définition de la fonctionalité du métier...

Ou alors nous n'avons pas les mêmes définitions de ce qu'est un métier ou un service métier...

Cela m'étonne également, je l'ai fait dans de nombreux projets mais là mon entreprise fait appel à une société de services qui nous disent que ce n'est pas possible avec leur architecture de faire des appels entre services métiers pour des raisons de gestion des transactions

[souviron34]

Alors 2 points :

Cela m'étonne également, je l'ai fait dans de nombreux projets mais là mon entreprise fait appel à une société de services qui nous disent que ce n'est pas possible avec leur architecture

C'est votre projet, ou le projet dans sa totalité est fait par la société de services ?

une société de services qui nous disent que ce n'est pas possible avec leur architecture de faire des appels entre services métiers pour des raisons de gestion des transactions

• Si le projet est fait par vous avec une partie sous-traitée :
  
  2 solutions
  
  
  • Ou vous ne faites pas appel à cette société
  • Ou vous obligez cette société à se conformer à vos exigences : c'est vous le demandeur, quand même. Ce n'est pas au prestatire à imposer des choix surtout de ce style.
  
  
  
• Si le projet est entièrement fait par la société de services, alors cela doit faire partie de votre cahier des charges. A eux de se débrouiller , soit qu'ils changent leur architecture, soit...

Si ce que tu dis est vrai, c'est assez fou

[sauzanne]

C'est surtout que question souplesse c'est vraiment pas terrible car inévitablement ça a tendance à faire de la redondance de code...

[souviron34]

ben non, c'est sutout que les règles métier sont ça, des règles métier.. Si elles nécessitent une communication entre diverses entités, ces communications doivent être possible...

Cela fait partie de la définition des besoins. Si le besoin a été exprimé et que l'architecture chosiie ne le permet pas, il faut changer l'architecture, pas le métier..

[sauzanne]

Après ça n'empêche pas de coder la partie métier pour le coup, c'est juste moins souple

[souviron34]

tu n'as pas répondu à ma question :

C'est votre projet, ou le projet dans sa totalité est fait par la société de services ?

C'est à dire donnez-vous un Cahier des Charges à respecter à ladite société de services, à charge pour elle de faire tout le code, ou bien avez-vous déjà une analyse des besoins, une architecture, une structure chez vous, et sous-traitez-vous une partie du code ?

[sauzanne]

tu n'as pas répondu à ma question :



C'est à dire donnez-vous un Cahier des Charges à respecter à ladite société de services, à charge pour elle de faire tout le code, ou bien avez-vous déjà une analyse des besoins, une architecture, une structure chez vous, et sous-traitez-vous une partie du code ?

C'est plus intégré que ça car nous avons un accès en permanence à leur code et au final nous avons défini de nombreux éléments d'architecture

[souviron34]

C'est plus intégré que ça car nous avons un accès en permanence à leur code et au final nous avons défini de nombreux éléments d'architecture

eh bien c'en est un

Il n'est pas normal qu'un prestataire dicte sa loi, surtout des choses par rapport au métier.

Si le métier le nécessite, eh bien qu'ils changent leurs règles.. plutôt que d'enlever de la souplesse et de rehausser les coûts de maintenance et les possibilités de bug ...

Plus il y a de "duplication", plus les risques sont grands déjà de bugs, ensuite d'éloignement des diverses portions "similaires" en fonction du temps, plus, dans un environnement assez méthodique, le temps et la complexité (et donc aussi le coût) des tests de régression...

Bref, c'est à éviter à tout prix.. Puisqu'on peut faire autrement, vu que c'est leur architecture qui ne correspond pas à ce que vous voulez..

[slim]

Bonjour,

Je me permets de m’immiscer dans la discussion...
Je pense qu'il y a un petit quiproquo ou j'ai mal compris.
On parle bien d'un service métier "technique" comme un service spring ? et non pas d'un service de l'entreprise ? J'ai l'impression que souviron34 parle d'un service de l'entreprise, non ?

En parlant bien d'un service métier "technique", je pense qu'il est tout à fait possible de faire appel à un autre service en faisant attention aux modes transactionnels des deux.

[souviron34]

Tu as raison sur le quiproquo possible.. mais pas (forcément) par rapport aux services de l'entreprise...

J'avais d'ailleurs précisé :

Ou alors nous n'avons pas les mêmes définitions de ce qu'est un métier ou un service métier...

Vu la rubrique et l'entête, j'ai supposé que ce n'était pas technique. mais pas forcément non plus un service différent de l'entreprise, mais simplement un "besoin" ou une "fonctionalité" métier différent(e).

J'ai - peut-être - sans-doute - mal supposé..

C'est sans doute dans un découpage style MCD ou autre..

De toutes façons, la problèmatique est la même, comme tu le mentionnes :

En parlant bien d'un service métier "technique", je pense qu'il est tout à fait possible de faire appel à un autre service en faisant attention aux modes transactionnels des deux.

Que ce soit en termes techniques, d'architecture, de modélisation, de fonctionalités, ou entre systèmes de différents services d'entreprise, il n'y a a priori aucun empêchement (surtout si c'est un besoin identifé) pour que cela ne se fasse pas.. Et si c'est un besoin identifié, il n'y a aucune raison valable qu'une équipe info, sous-traitante ou non, refuse de le mettre en place..