Que signifie réellement «logique métier» sinon «tout code non tiers»?

J'ai entendu beaucoup de gens parler de la logique métier au travail et en ligne, et j'ai lu plusieurs questions sur ce site à ce sujet, mais le terme n'a toujours pas beaucoup de sens pour moi. Par exemple, voici quelques déclarations (paraphrasées) que je vois souvent:

• "La logique métier est la partie de votre programme qui code les règles métier réelles." La plupart des définitions que j'ai lues sont circulaires comme celle-ci.

• "La logique métier est tout ce qui est unique à votre application particulière." Je ne vois pas en quoi cela est différent de "votre application particulière n'est rien d'autre que la logique métier", à moins que nous n'ayons accidentellement réinventé un tas de roues pour lesquelles nous aurions pu utiliser un logiciel tiers existant. D'où le titre de la question.

• "Il devrait y avoir une couche de logique métier au-dessus de votre couche d'accès aux données et en dessous de votre couche GUI." Dans le code que j'écris, les accesseurs de la base de données doivent savoir à quelles données ils sont censés accéder, et le code de l'interface utilisateur doit en savoir beaucoup sur ce qu'il affiche afin de l'afficher correctement, et il n'y a rien à vraiment faire entre les deux. ces deux endroits autres que le transfert de taches de données entre le client et le serveur. Alors, qu'est-ce qui est censé entrer dans une couche de logique métier?

• "La logique métier doit être distincte de la logique de présentation." La plupart des demandes de fonctionnalités que nous recevons visent à modifier la logique de présentation pour des raisons commerciales. Si l'une des règles commerciales consiste à afficher les prix des obligations du gouvernement américain en notation 32nds par défaut (tout en fournissant également une interface utilisateur pour que l'utilisateur puisse le configurer), la logique de présentation doit au moins savoir que cette règle existe, sinon la mettre en œuvre complètement. En outre, il semble qu'une partie importante de la conception UX aide l'utilisateur à comprendre les règles métier que notre logiciel essaie de mettre en œuvre.

Est-il possible que je sois réellement dans une équipe qui ne fait que de la logique métier, et que toute la logique non-business soit faite par d'autres équipes? Ou est-ce que tout le concept de «logique métier» en tant qu'entité distincte ne fonctionne que pour certaines applications ou architectures?

Pour aider à concrétiser les réponses: Imaginez que vous devez réimplémenter l'application Domino's Pizza. Quelle est la logique métier et quelle est la logique non commerciale de cette application? Et comment serait-il possible de mettre cette logique commerciale de commande de pizza dans sa propre "couche" de code, sans que la plupart des informations sur la pizza ne se retrouvent dans les couches d'accès aux données et de présentation?

Mise à jour: Je suis arrivé à la conclusion que mon équipe utilise probablement 90% de code d'interface utilisateur et la plupart - mais pas la totalité - de ce que vous appelleriez la logique métier provient d'autres équipes ou entreprises. Fondamentalement, notre application est pour la surveillanceles données financières, et presque toutes les fonctionnalités sont des moyens pour l'utilisateur de personnaliser les données qu'il voit et comment il les voient. Il n'y a pas d'achat ou de vente en cours (bien que nous nous intégrions un peu aux autres applications de notre entreprise qui le font), et les données réelles sont fournies par de nombreuses sources externes. Mais nous permettons aux utilisateurs de faire des choses comme envoyer des copies de leurs «moniteurs» à d'autres utilisateurs, donc les détails de la façon dont nous traitons cela peuvent probablement être considérés comme de la logique métier. Il y a en fait une application mobile qui parle actuellement à certains de notre code backend, et je sais exactement quelle partie de notre code frontend je voudrais qu'elle partage avec notre interface utilisateur dans un monde idéal (essentiellement le M dans notre quasi-MVC) donc Je suppose que c'est le BLL pour nous.

J'accepte la réponse de user61852 car elle m'a donné une compréhension beaucoup plus concrète de ce que la «logique métier» fait et ne fait pas référence.

Je vais vous donner quelques conseils concernant les applications CRUD , car je n'ai pas beaucoup d'expérience dans les jeux ou les applications graphiques intensives:

• La logique commerciale implique généralement des règles que le propriétaire de l'entreprise a apprises ou décidées au cours des années de fonctionnement, comme par exemple: "rejeter tout nouveau crédit si le client n'a pas encore fini de payer le dernier" , ou "nous ne vendons pas de petit-déjeuner après 11 h " ou " les lundis et mardis, les clients peuvent acheter deux pizzas pour le prix d'une " .
• Bien sûr, la couche de présentation doit afficher un message indiquant la disponibilité d'une remise ou la raison du rejet d'un crédit, mais cette couche ne décide pas de ces choses, elle ne fait que communiquer à l'utilisateur quelque chose qui s'est passé sous le capot.
• La logique métier implique généralement un workflow , par exemple: "cet article doit être approuvé dans les 3 jours ouvrables par un responsable ou mis dans une phase de" demande d'informations ", si le client n'a pas soumis les documents requis, alors l'article est rejeté" .
• La couche de présentation ne traite généralement pas ce type de flux de travail, elle reflète uniquement les états du flux de travail.
• En outre, la couche d'accès aux données est généralement simple, car les décisions ont déjà été prises par la logique métier. Cette couche est affectée lorsque vous décidez de migrer vos données de MS SQL Server vers Oracle, par exemple
• Il est vrai que parfois l'interface graphique effectue une certaine validation pour éviter les appels au serveur, mais c'est quelque chose qui devrait être fait judicieusement ou vous pourriez avoir beaucoup de logique métier dans cette couche.
• Une grande partie de votre confusion est peut-être due au fait que dans votre application, il n'y a pas de séparation des préoccupations et que vous avez en réalité trop de logique métier dans la couche de présentation. Le fait que vous ayez (à tort) une logique métier dans votre couche application ou couche d'accès aux données ne change en rien le fait que ce soit la logique métier.
• Des choses comme l'affichage des distances dans le système métrique au lieu de miles / yards / pieds n'est pas une logique de présentation, c'est une logique métier . La couche métier doit renvoyer des données dans les unités requises et indiquer à la couche de présentation quelles unités elle gère pour qu'elle affiche les étiquettes appropriées, mais c'est certainement une préoccupation de logique métier.
• La logique métier ne devrait pas être affectée par le fait que vous utilisez maintenant Oracle au lieu de Postgres, ou par le fait que l'entreprise a changé son logo ou sa feuille de style.
• Les règles métier existent, que vous les automatisiez ou non en écrivant une application. Ils peuvent être appliqués même lorsque l'entreprise utilise une solution à faible technologie comme le stylo et le papier.
• Si vous avez une version mobile de votre application de bureau ou une version Web , chacune de ces versions a une couche de présentation différente , mais (espérons-le) la même couche métier.

Il semble que la plupart de votre travail se trouve dans la couche d'interface utilisateur. La modification du format d'affichage pour des raisons professionnelles n'implique aucune logique métier. Le changement est un changement de la logique de vue.

La possibilité de modifier le format implique une certaine logique métier impliquant éventuellement la persistance de la préférence.

La persistance du format dans un cookie peut également être implémentée dans la couche d'affichage.

Cependant, cela pourrait être implémenté de manière MVC. (Certains modèles implémentent la vue comme son propre MVC capable de gérer les préférences.)

• La préférence de l'utilisateur peut être enregistrée par le modèle (base de données / cookie).
• Le contrôleur réagirait aux demandes de format en modifiant la préférence de l'utilisateur dans le modèle.
• La vue s'adapterait aux préférences de l'utilisateur. La préférence peut être demandée au modèle ou fournie par le contrôleur.

Faire une estimation éclairée de votre application.

• Il existe un modèle contenant les obligations disponibles et des données de tarification pour celles-ci.
• Il existe une vue permettant à l'utilisateur de voir diverses choses qu'il peut faire: rechercher des obligations, afficher les prix, comparer les rendements, prendre des commandes et qui affiche les résultats renvoyés par le modèle économique en réponse à la demande.

• La logique métier gère des choses comme:

  • Effectuer une recherche et prévoir l'affichage de la vue.
  • Trouver les prix d'une caution et prévoir l'affichage de la vue.
  • Comparer les rendements et fournir des données à afficher.
  • Traiter les commandes et les stocker dans le modèle.

Si cela est fait correctement, il devrait être possible de fournir plusieurs composants de vue sans changer le modèle ou la logique métier. Par exemple, si la conception actuelle est un site Web, un nouveau serveur de vue pour une application iPhone ou Android utiliserait le modèle et la logique métier existants. Ceux-ci peuvent introduire de nouvelles fonctionnalités commerciales pour fournir des notifications push lorsqu'une commande est exécutée, ce qui peut nécessiter des modifications sur plusieurs couches.

Cette ventilation permet de séparer les préoccupations.

• La couche de données représentée par le modèle a tendance à être relativement stable.
• La couche métier est l'endroit où les décisions commerciales sont appliquées: la demande sera-t-elle ou pourra-t-elle être satisfaite? Toutes les données requises ont-elles été obtenues? L'utilisateur est-il autorisé? Y a-t-il des drapeaux rouges sur la transaction?
• La couche de visualisation a tendance à être moins stable et il peut y en avoir plusieurs. C'est là que réside l'aspect et la convivialité de l'application. Il est possible de recouvrir complètement une application, sans changer les autres couches.