En quoi consiste exactement la « logique métier » dans une application ?

Question

J'ai entendu à maintes reprises que nous « ne devrions pas mélanger la logique métier avec d'autres codes » ou des déclarations de ce type.Je pense que chaque code que j'écris (les étapes de traitement, je veux dire) consiste en une logique liée aux exigences de l'entreprise.

Quelqu'un peut-il me dire en quoi consiste exactement la logique métier ?Comment le distinguer des autres codes ?Existe-t-il un test simple pour déterminer ce qu'est la logique métier et ce qui ne l'est pas ?

Answer 1

Définissez simplement ce que vous faites dans un anglais simple.Lorsque vous dites des choses d'un point de vue commercial, comme « faire souffrir ceux-là », « voler cet argent », « détruire cette partie de la terre », vous parlez de couche commerciale.Pour que ce soit clair, les choses qui vous enthousiasment vont ici.

Lorsque vous dites « montrez ceci ici », « ne montrez pas cela », « rendez-le plus beau », vous parlez de la couche de présentation.Ce sont ces choses qui enthousiasment vos designers.

Lorsque vous dites des choses comme "enregistrer ceci", "obtenir ceci de la base de données", "mettre à jour", "supprimer", etc.vous parlez de la couche de données.Ce sont ces choses qui vous disent ce qu’il faut garder pour toujours à tout prix.

Answer 2

Il est probablement plus facile de commencer par dire quoi n'est-ce pas logique métier.L'accès à la base de données ou au disque n'est pas une logique métier.L'interface utilisateur n'est pas une logique métier.Les communications réseau ne relèvent pas d’une logique métier.

Pour moi, la logique métier correspond aux règles qui décrivent le fonctionnement d’une entreprise, et non le fonctionnement d’une architecture logicielle.La logique métier a également tendance à changer.Par exemple, il peut s'agir d'une exigence commerciale selon laquelle chaque client doit disposer d'une seule carte de crédit associée à son compte.Cette exigence peut évoluer afin que les clients puissent disposer de plusieurs cartes de crédit.En théorie, cela devrait simplement être un changement dans la logique métier et les autres parties de votre logiciel ne seront pas affectées.

C'est donc de la théorie.Dans le monde réel (comme vous l'avez constaté), la logique métier a tendance à se propager dans tout le logiciel.Dans l'exemple ci-dessus, vous devrez probablement ajouter une autre table à votre base de données pour contenir les données supplémentaires de la carte de crédit.Vous devrez certainement changer l'interface utilisateur.

Les puristes disent que la logique métier doit toujours être complètement séparée et seraient donc même contre l'idée d'avoir des tables nommées "Clients" ou "Comptes" dans la base de données.Poussé à l'extrême, vous vous retrouveriez avec un système incroyablement générique et impossible à maintenir.

Il existe certainement un argument solide en faveur du maintien de la majeure partie de votre logique métier plutôt que de la disperser dans tout le système, mais (comme pour la plupart des théories), vous devez être pragmatique dans le monde réel.

Answer 3

Je pense que vous confondez la logique métier avec les exigences de votre application.Ce n'est pas la même chose.Quand quelqu’un explique la logique de son entreprise, c’est quelque chose comme :

"Lorsqu'un utilisateur achète un article, il doit fournir des informations de livraison.Les informations sont validées avec les règles x y z.Après cela, il recevra une facture et gagnera des points, ce qui lui donnera x% de réduction pour les y offres" (désolé pour le mauvais exemple)

Lorsque vous mettrez en œuvre ces règles métier, vous devrez penser à des exigences secondaires, comme la façon dont les informations sont présentées, comment elles seront stockées de manière persistante, la communication avec les serveurs d'applications, comment l'utilisateur recevra la facture, etc.Toutes ces exigences ne font pas partie de la logique métier et doivent en être découplées.De cette façon, lorsque les règles métier changent, vous adapterez votre code avec moins d'effort.C'est un fait.

Parfois, la présentation reproduit une partie de la logique métier, principalement en validant les entrées de l'utilisateur.Mais il doit également être présent dans la couche de logique métier.Dans d'autres situations, il est nécessaire de déplacer une partie de la logique métier vers la base de données, pour des problèmes de performances.Ceci est discuté par Martin Fowler ici.

Answer 4

Pour simplifier les choses sur une seule ligne...
La logique métier serait un code qui ne dépend pas/ne changera pas avec un détail d'interface utilisateur/d'implémentation spécifique.Il s'agit d'une représentation codée des règles, des processus, etc.qui sont définis par/reflètent l’entreprise modélisée.

Answer 5

Je n'aime pas les noms BLL+DAL des calques, ils prêtent plus à confusion qu'à clarifier.
Appelez-le DataServices et DataPersistence.Cela rendra les choses plus faciles.

Services de manipulation, CRUD de niveau de persistance (créer, lire, mettre à jour, supprimer)

Answer 6

Pour moi, " logique métier " constitue toutes les entités qui représentent les données applicables au domaine problématique, ainsi que la logique qui décide de " que faire des données ".

Il devrait donc vraiment s'agir de "transport de données" (et non d'accès) et de "manipulation de données".En fait, l'accès aux données (les éléments frappant la base de données) devrait se faire dans une couche différente, tout comme le code de présentation.

Answer 7

S'il contient quelque chose sur des éléments comme un formulaire, un bouton, etc.ce n'est pas une logique métier, c'est une couche de présentation.S'il contient de la persistance dans un fichier ou une base de données, c'est DAL.Tout ce qui se trouve entre les deux relève de la logique métier.En réalité, tout ce qui n'est pas lié à l'interface utilisateur est parfois appelé « logique métier », mais cela devrait concerner le domaine problématique, et non la gestion interne.

Answer 8

La logique métier est une pure abstraction, elle existe indépendamment de la matérialisation/visualisation des données devant votre utilisateur et indépendamment de la persistance des données sous-jacentes.

Par exemple, dans un logiciel de préparation de déclarations de revenus, l'une des responsabilités des classes de logique métier serait le calcul de la taxe à payer.Ils ne seraient pas responsables de l’affichage des rapports ni de la sauvegarde et de la récupération d’une déclaration de revenus.

---

@Lars, "services" implique une certaine architecture.