Quelle est la différence entre la logique métier et la logique applicative?
Veuillez noter que j'ai posé la même question sur stackoverflow mais ils m'ont demandé de poser ici.
Alors que j'essaie de discerner la différence entre la logique d'application et la logique métier, j'ai trouvé un ensemble d'articles, mais malheureusement, il y a une contradiction entre eux.
Ici ils disent qu'ils sont les mêmes mais la réponse ici est totalement différente.
Pour moi, je le comprends de la manière suivante:
Si nous recherchons la définition du mot Logic dans Google, nous obtiendrons
système ou ensemble de principes qui sous-tendent la disposition des éléments dans un ordinateur ou un appareil électronique de manière à effectuer une tâche spécifiée.
Donc, si la logique est set of principles underlying the arrangements of elements alors la logique métier doit être set of principles underlying the arrangements of the business rules, en d'autres termes, cela signifie que les règles à suivre pour obtenir un système reflètent les besoins de votre entreprise.
Et pour moi, la logique d'application est the principles that the application based on, en d'autres termes, comment appliquer ces règles pour qu'un système reflète les besoins de votre entreprise, par exemple dois-je utiliser MVC ou ne pas utiliser?, dois-je utiliser SQL ou MSSQl ?.
Alors, s'il vous plaît, quelqu'un pourrait-il m'aider à me débarrasser de la confusion concernant la différence entre l'application et la logique métier.
Je suis d'accord avec LoztInSpace de SO que c'est une réponse assez d'opinion et que tout le monde peut avoir des définitions légèrement différentes. Surtout si des influences historiques sont impliquées. Voici comment je définirais les termes:
La logique métier est une logique créée avec la collaboration et l'accord des experts métier. Si l'expert en affaires dit que "le client ne peut pas retirer plus d'argent qu'il n'en a sur son compte", il s'agit d'une règle commerciale. Dans un monde idéal, cette logique se trouverait dans une sorte de bibliothèque ou de service, elle peut donc être réutilisée dans plusieurs applications ou modifiée dans toutes les applications pertinentes à la fois.
La logique d'application est tout simplement tout le reste. Par exemple, "cliquer sur ce bouton ouvre une fenêtre pour ajouter un nouveau client". Cela n'a rien à voir avec les affaires, mais c'est toujours une logique qui doit être mise en œuvre. Dans le monde idéal, la logique d'application utilisera une bibliothèque ou un service, c'est-à-dire la mise en œuvre des règles métier. Plusieurs applications, chacune avec une logique d'application différente, peuvent réutiliser une logique métier. Imaginez une application Web, un service Web et une application mobile fonctionnant tous selon une même logique métier, mais chacun a clairement besoin de logiques d'application différentes.
La raison pour laquelle je pense que ces deux-là se confondent, c'est qu'il est extrêmement difficile de les séparer. Même si vous faites de votre mieux pour les séparer, utilisez des cas où vous devez les mélanger. Si, par exemple, vous avez toute votre logique métier en service, elle la garde séparée. Mais avoir une logique métier dans l'application locale qui utilise le service peut augmenter la réactivité ou le confort de l'utilisateur, car l'application locale n'a pas besoin d'appeler le service pour chaque petit changement.
Une autre raison pour laquelle ils sont mélangés est que pour de nombreuses personnes non techniques. L'interface utilisateur est "l'application", donc tout ce qui se reflète dans l'interface utilisateur est important. Dans le cas idéal de la "logique métier", il n'y a pas d'interface utilisateur. Il y aurait probablement une suite de tests automatisés pour vérifier la logique, mais rien qui puisse être montré aux gens d'affaires. Donc, pour les gens d'affaires, tout est du même genre de "logique". OMI.
Comme d'autres l'ont souligné, ces termes n'ont pas un sens universellement accepté. Je décrirai les définitions que j'ai rencontrées plus souvent, c'est-à-dire dans plusieurs projets avec différentes entreprises.
logique métier définit un modèle normalisé à usage général du domaine métier pour lequel une application est écrite, par ex.
- Des classes comme
Customer,Order,OrderLineet des associations commecustomer-order, etc. - Opérations générales telles que
registerCustomer,cancelOrder
Très souvent, ce modèle de classe est mappé à un modèle de base de données et le mappage est implémenté à l'aide d'ORM. Les opérations sont normalement effectuées chacune dans leur propre transaction et fournissent l'API de base pour modifier la base de données, c'est-à-dire l'état persistant de l'application.
logique d'application est une couche construite au-dessus de la logique métier et sert à implémenter des cas d'utilisation spécifiques. Les modules logiques d'application peuvent utiliser une représentation de données ad hoc, par ex. une classe CustomerSummary sans association avec Order si vous souhaitez répertorier uniquement les clients. Cette représentation de données ad hoc doit être mise en correspondance avec la représentation normalisée sous-jacente fournie par le modèle commercial. Par exemple, CustomerSummary peut être défini comme une vue au-dessus de Customer.
Notez que la frontière entre les deux couches peut ne pas être aussi clairement définie. Par exemple. après avoir implémenté plusieurs cas d'utilisation, on peut remarquer des structures de données similaires dans la logique d'application et décider de les unifier (normaliser) et de les déplacer vers la logique métier.
Chaque système ou application va avoir ses propres définitions de la logique métier et de la logique applicative. Ce sera explicite ou implicite.
D'après mon expérience, les applications pilotées par les données (par exemple, les bases de données, etc.) ont tendance à avoir une définition plus formelle de la logique métier.
La logique d'application a tendance à se concentrer sur l'obtention d'informations du point A au point B, la logique métier est centrée sur ce que sont les informations - et le langage de la logique métier est généralement spécifique au domaine. Autrement dit, la logique d'application se concentre sur la question "comment ça marche?", La logique métier sur "que fait-elle? - encore une fois, la distinction peut être très floue et n'est le plus souvent pas spécifique à un domaine.
Na, ce ne sont que des termes différents pour la même chose - le "niveau intermédiaire" du code de programme qui fait les choses que vous voulez que votre programme exécute. Comme beaucoup de choses dans les logiciels, il n'y a pas de terminologie stricte et rapide pour les parties d'un système, car il n'y a pas de définitions formelles uniques pour les systèmes de construction.
Ainsi, parfois, les gens l'appelleront la logique métier, d'autres la logique d'application, d'autres l'appelleront la logique de programme, c'est tout un truc. Ne vous embêtez pas à essayer de définir cela de manière si rigide, presque tous les systèmes varient dans la façon dont ils sont construits, alors soyez heureux qu'il n'y ait que ce faible niveau d'imprécision dans la terminologie!