La décision de créer une couche de service dépend de nombreux facteurs. J'ai créé des couches de service dans le passé pour les raisons suivantes.
- Code devant être réutilisé par plusieurs clients.
- Bibliothèques tierces pour lesquelles nous avons des licences limitées.
- Les tiers qui ont besoin d’un point d’intégration dans notre système.
- Centraliser la logique métier dupliquée.
Cas 1: Vous créez une fonctionnalité de base qui doit être utilisée par une multitude de clients. La couche de service crée des fonctionnalités pour différents clients afin de puiser dans les fonctionnalités fournies immédiatement.
Cas 2: Vous hébergez normalement du code dans une application, mais vous utilisez une bibliothèque tierce pour laquelle vous disposez de licences limitées. Dans ce cas, vous avez une ressource que vous souhaitez utiliser partout, mais seulement un nombre limité d’entre elles. Si vous l'hébergez derrière un service, votre organisation tout entière peut en tirer parti à partir de leurs applications sans avoir à acheter une licence pour chaque hébergement individuel.
Cas 3: Vous créez une fonctionnalité pour que des tiers puissent communiquer avec vous. Dans votre exemple, vous pouvez configurer un point de terminaison d'inventaire pour permettre aux fournisseurs de vous transmettre des messages sur les envois de produits entrants.
Cas n ° 4: Vous avez analysé votre code à l’échelle de votre entreprise et constaté que des équipes distinctes avaient créé la même chose (la mise en œuvre était légèrement différente). Avec une couche de service, vous pouvez choisir la ou les meilleures approches et maintenant, vous pouvez implémenter le processus de la même manière pour toutes les équipes en les faisant appeler. Un autre avantage de la logique centralisatrice réside dans la découverte de bogues. Maintenant, vous pouvez déployer le correctif une fois et tous les clients profitent des avantages en même temps.
Tout cela étant dit, il existe des inconvénients potentiels pour une couche de service.
- Ajoute la complexité du système. Là où vous n'aviez auparavant qu'une seule application à déboguer, vous en avez maintenant deux. Les problèmes de production nécessitent la vérification des paramètres des applications client, des paramètres des applications de service ou des problèmes de communication entre des applications client et serveur configurées correctement. Cela peut être délicat si vous ne l'avez jamais fait auparavant.
- Un point d'échec. En cas de panne de service, tous les clients sont concernés. Lorsque le code n'est pas déployé de cette manière, le risque peut être moindre (bien qu'il existe des moyens de le réduire).
- Le contrôle de version peut être plus difficile à faire. Lorsque vous utilisez une application utilisant un service déployant une interface, des modifications peuvent être apportées simultanément. Lorsque vous avez plusieurs clients, vous devez gérer qui est sur la V1, qui est sur la V2 et coordonner la suppression de la V1 (une fois que vous savez que tout le monde a mis à jour vers la V2).
Le point principal est que ce n’est pas toujours un slam dunk de rendre votre système orienté services. D'après mon expérience, c'est généralement une bonne idée (j'ai tendance à structurer les applications de cette manière), mais ce n'est pas une décision automatique. En fin de compte, vous devez peser le pour et le contre et prendre la décision qui convient à votre situation.