La logique métier doit-elle être dans l'application ou dans le backend?
J'ai récemment commencé à appliquer l'architecture propre tout en développant une application Android. J'ai donc divisé mon application en 4 parties différentes.
Couche de données
Contient l'implémentation de référentiels.
Couche de périphérique
Contient l'implémentation de Android des trucs liés comme AlarmManager, non liés au stockage des entités.
Couche de domaine
Les cas d'utilisation (interacteurs) sont implémentés ici et les interfaces pour les référentiels sont définies ici.
Présentation
Objets liés à l'interface utilisateur, fragments, modèles de vue, activités.
Cette application n'est pas isolée, elle existe dans un système avec un backend et un frontend (application web) où certains utilisateurs utilisent l'application mobile et certains utilisent l'application web.
Maintenant, selon l'architecture propre, la logique métier devrait résider dans la couche domaine. Mais dans ce scénario, j'ai l'impression qu'il n'y appartient pas. Prenons un exemple.
Supposons qu'un utilisateur puisse acheter des MovieTickets dans différents types de cinémas.
Dans ce scénario, nous aurions un cas d'utilisation appelé PurchaseMovieTicket.
Maintenant, la question est. Où la logique réelle de l'achat doit-elle être mise en œuvre? Il y a deux façons de procéder.
Type 1
La plupart des exemples d'architecture propre sur Android considèrent uniquement le référentiel comme quelque chose pour effectuer des opérations CRUD, que ce soit sur le cloud ou sur le stockage local (par exemple. Android Room)) Cela signifierait que le cas d'utilisation PurchaseMovieTicket inclurait une logique telle que.
- Retirer de l'argent à l'utilisateur
- Ajouter le ticket de cinéma à l'utilisateur
- Mise à jour des appels sur le référentiel avec le paramètre Utilisateur en tant que
Maintenant, les inconvénients ici sont évidents. Et si le back-end doit faire d'autres choses liées à l'achat de billets de cinéma, peut-être même communiquer avec d'autres systèmes, alors tout cela devrait également être implémenté dans l'application. Vous pouvez presque voir comment cela n'est pas possible.
Type 2
Le référentiel contient une méthode appelée PurchaseMovieTicket qui prend un MovieTicket et un utilisateur. Cette méthode ferait la logique nécessaire sur le backend ou partout où elle est implémentée.
L'inconvénient ici est bien, le cas d'utilisation devient presque inutile car il transfère simplement l'appel du modèle de vue au référentiel. Et il n'y a pas de logique commerciale dont parler.
Question
- Quel type serait le meilleur à utiliser dans ce système? Pourquoi?
- Est-il bon de mettre la logique métier dans le backend?
- Si vous optez pour l'implémentation de type 2, le référentiel casse-t-il les principes d'architecture propre?
Cela devrait être au cas par cas, mais je m'attendrais à ce que la majeure partie de la logique aille dans le backend.
Votre interacteur peut encore contenir plusieurs méthodes ("Vérifier la disponibilité des tickets", "Ajouter un ticket au panier", "Commander") mais oui, l'implémentation pourrait être très simple dans certains cas.
Vous pourriez envisager:
Sécurité. Tout code auquel vous devez faire confiance, implémentez-le sur le backend. Supposons qu'un pirate puisse modifier le code client pour faire ce qu'il veut. Dans votre exemple de type 1, que se passe-t-il s'ils l'ont modifié pour appeler uniquement "Ajouter le ticket de film à l'utilisateur" et non "Retirer de l'argent à l'utilisateur"?
couplage de communication. Comme vous le mentionnez, pour tout ce qui a besoin de communiquer avec d'autres systèmes, préférez le backend pour que le client ait seulement besoin de communiquer avec votre backend.
réactivité. Les choses côté client (en dehors des calculs lourds) auront généralement de meilleures performances pour l'utilisateur que de communiquer avec le backend. Quelque chose comme le calcul d'un prix total du panier pourrait être mieux du côté client pour cette raison.
Duplication. Si vous avez deux clients, l'implémentation de la logique dans le client nécessitera sa duplication, donc préférez le backend.
Emplacement des données. Préférez mettre la logique avec les données sur lesquelles il opère. Par exemple, si cela nécessite de calculer sur un grand nombre de données de la base de données backend, mais envoie seulement un petit résultat à l'utilisateur, mettez cette logique dans le backend. Ou l'inverse pourrait s'appliquer.
API . Préférez placer la logique pour que l'API du backend soit cohérente et cohérente.
Conditions de course. Placer la logique dans le backend rend l'utilisation des transactions et des techniques similaires beaucoup plus faciles, ce qui réduit le risque de problèmes de concurrence.
Besoins en ressources. Sur mobile, je suggère que le calcul lourd soit effectué sur le backend. S'il s'agissait d'une application de bureau connue pour ne fonctionner que sur des machines décentes, il serait préférable de préférer l'extrémité client pour réduire la charge du serveur.
Notez que ce n'est pas une liste exhaustive.
La définition même des termes "front end" et "back end" provient de la séparation de la logique métier (back end) de l'interface utilisateur (front end). Alors oui, la logique métier devrait être dans le back-end, que ce soit un service distant ou simplement une couche différente dans la même application.
Étant donné que vous disposez déjà d'un système principal distinct, vous devez appliquer l'architecture propre principalement à ce système, qui devrait contenir toute la logique métier. L'application mobile peut être considérée comme une extension de la couche d'interface utilisateur du système principal et n'a donc pas de logique métier propre. Tous les cas d'utilisation et les référentiels vivent dans le back-end, et l'application mobile utilise simplement une passerelle pour parler au back-end.
Im un DBA pas un développeur, donc je vais vous offrir une perspective pro db.
L'implémentation de la logique à l'aide d'une combinaison de proc stockés et de valeurs pilotées par table dans la base de données qui peut être partagée à la fois par l'application Web et l'application mobile signifie que vous obtenez la sécurité, les performances et la cohérence.
Il présente l'avantage supplémentaire que lorsque vous souhaitez effectuer une modification, cette modification est immédiatement déployée pour tous les utilisateurs, quelle que soit l'interface.
Cela signifie également que des changements de comportement peuvent être effectués par l'entreprise sans avoir à redéployer le logiciel.