Quelle est vraiment la "logique métier"?
Je travaille avec le développement web depuis 2009, quand j'ai commencé avec PHP. Lorsque je suis passé à ASP.NET, j'ai beaucoup entendu parler de DDD et OOAD où une grande attention est accordée à cette "logique métier" et "règles métier". Le fait est que toutes les applications que j'ai développées jusqu'à présent concernaient toutes les opérations CRUD et je n'ai jamais vu ces choses dans la pratique.
Je ne peux tout simplement pas imaginer ce que ces choses peuvent vraiment être en pratique. Alors, quelle est vraiment cette logique métier et comment cela s'intègre dans une application? Je sais que celles-ci sont implémentées en tant que méthodes dans les modèles de domaine, mais quelles pourraient être ces méthodes et où, dans l'application, elles pourraient éventuellement être utilisées?
CRUD est un acronyme qui signifie créer, lire, mettre à jour et supprimer. Ce sont les quatre opérations de base que vous pouvez effectuer sur un Tuple de base de données. Mais il y a toujours plus dans les applications métier que de créer, lire, mettre à jour et supprimer des enregistrements de base de données.
Commençons par quelques définitions de base, puis examinons quelques exemples et voyons comment ces définitions correspondent aux exemples et comment elles correspondent au logiciel réel.
Business logic ou la logique du domaine est cette partie du programme qui code les règles métier du monde réel qui déterminent comment les données peuvent être créées, stockées et modifiées. Il prescrit la manière dont les objets métier interagissent entre eux et applique les itinéraires et les méthodes par lesquels les objets métier sont accessibles et mis à jour.
Business Rules décrivent les opérations, définitions et contraintes qui s'appliquent à une organisation. Les opérations forment collectivement un processus; chaque entreprise utilise ces processus pour former des systèmes qui font avancer les choses.
Maintenant, travaillons avec quelques exemples.
Transférer de l'argent d'un compte courant à un autre
Tout d'abord, quelles sont les choses que vous devez savoir (entrée)?
- L'identité de la personne effectuant le transfert
- Le montant d'argent à transférer
- Le numéro de compte de vérification de la source
- Le numéro de compte de contrôle cible
Quelles sont les "règles commerciales" qui doivent être appliquées?
- La personne qui fait la demande doit avoir le pouvoir de le faire.
- La transaction doit être atomique .
- La transaction peut avoir des obligations de déclaration au gouvernement, si elle dépasse un certain montant
Par "atomique", je veux dire que la transaction doit réussir complètement ou échouer complètement. Vous ne pouvez pas avoir de transactions de compte où l'argent est retiré d'un compte sans arriver dans l'autre (l'argent disparaît) ou l'argent est déposé sur un compte, mais pas débité d'un autre compte (l'argent apparaît comme par magie de nulle part).
Commander quelque chose d'Amazon.
Qu'avez-vous besoin de savoir?
- L'identité de la personne qui commande
- Informations sur la livraison
- Détails de facturation
- Moyen de paiement
- Montant et quantité de chaque article à expédier
- Comment expédier (nuit, bateau lent ou super économiseur)
- Taux d'imposition de l'État
Que se passe-t-il après la commande?
- Les articles sont retirés du stock
- Les quantités en stock sont débitées
- Les articles sont emballés pour l'expédition
- Les articles en rupture de stock sont en rupture de stock
- Les articles qui descendent en dessous des quantités minimales sont commandés
- Un envoi ou deux?
Une facture/liste d'expédition est imprimée et placée avec la commande
..etc.
CRUD est simplement la création, la lecture, la mise à jour, la suppression d'une application.
Dans une certaine mesure, un traqueur de bogues est également une application CRUD. Créer des bogues, lire (afficher) les bogues, mettre à jour les bogues et peut-être les supprimer.
Cependant, un tracker de bogue ne se limite pas à CRUD.
- Un développeur n'est pas autorisé à marquer le bogue comme vérifié ou fermé - cela fait partie du travail de QA. Et donc du code est là pour s'assurer que quelqu'un qui n'a pas le rôle de QA ne peut pas marquer un bogue comme fermé ou vérifié.
- Personne sauf un chef de projet ne peut réellement supprimer un bug.
- Pour qu'un bogue soit marqué comme "testez-moi", il doit y avoir au moins une validation de code contre le bogue.
- Seul un bogue qui est à l'état "fermé" peut être déplacé à l'état "rouvrir"
- Le développeur affecté au bogue ne peut pas le déplacer de "révision de code" à "révision de code terminée"
- Le contrôle qualité et les développeurs ne peuvent voir que les bogues des projets auxquels ils sont affectés.
Le code qui implémente ce qui précède est la logique métier de l'application.
La restriction des workflows, ou qui peut effectuer les différentes opérations dans CRUD. C'est ce qui sépare une application CRUD d'une autre. Ce sont les parties dont vous avez besoin pour que l'entreprise dise réellement comment l'application fonctionne. Comme c'est logique ... eh bien, c'est mieux de discuter autour d'une bière hors de portée du chef de projet. Mais c'est ce qu'est la logique métier.
Bien sûr, il est possible d'écrire une application CRUD "pure" où il n'y a pas de rôles, tout peut être modifié et affiché - mais ce sont l'exception plutôt que la règle.
La logique métier est la logique que vous écrivez dans votre programme pour gérer les règles métier qui vous sont données.
Lorsque vous commencez à entrer dans les règles métier, cela a tendance à se situer à un niveau plus élevé que le crud lui-même ou la logique métier. Ce sont généralement les choses que vous obtenez d'un analyste d'entreprise qui travaille avec l'entreprise.
Considérez dans cet exemple, un programme qui détermine comment gérer le retour d'un article à un bureau des retours dans un magasin.
- Si le reçu est égal ou supérieur à 90 jours, seul le crédit en magasin peut être accordé
- Si le reçu date de moins de 90 jours, créditez l'offre avec laquelle le reçu a été utilisé pour acheter (le crédit revient sur la carte de crédit, l'argent revient en espèces, le crédit en magasin va en crédit en magasin) ... à moins était un chèque, auquel cas utiliser de l'argent comptant.
Ce sont des règles commerciales. Ils ne parlent pas de la partie CRUD de la demande.
Lorsque vous travaillez avec des règles métier, vous pouvez souvent les trouver écrites dans un moteur de règles (par exemple, Windows Workflow Foundation Rules Engine ) au lieu d'écrire le code brut dans votre système.
Sachez que la distinction logique/règles est une distinction de terminologie et peut être argumentée toute la nuit (mieux sur une bière). Bien que ce ne soit pas une distinction rare, bien que les deux puissent se fondre l'un dans l'autre.
D'autres réponses sont correctes. Une pensée supplémentaire…
La logique métier est portable
Si vous deviez réimplémenter un projet logiciel dans un langage de programmation différent, dites passer de Turbo Pascal à Java , la logique métier & les règles métier est ce que les anciens et nouveaux projets auraient en commun .
Le langage de programmation serait différent. Le code source serait entièrement différent. Les outils ( [~ # ~] ide [~ # ~] s, compilateurs , etc.) peuvent être entièrement différents. L'interface utilisateur peut être entièrement réorganisée ou avoir une apparence différente . La documentation serait probablement différente. Mais le but des deux projets, les résultats finaux du travail effectué/les objectifs atteints, seraient les mêmes.
La logique métier se compose essentiellement de 2 grandes catégories: validation et flux. La logique métier stipule que la quantité 1 doit être supérieure ou égale à la quantité 2 - par exemple, le nombre d'articles à acheter doit être inférieur ou égal au nombre d'articles en stock.
Dans une application, les gens d'affaires diront qu'il s'agit d'une règle métier, et vous écrivez donc du code pour appliquer cette logique métier (validation). Une autre application dira que si le nombre d'articles commandés est supérieur au nombre d'articles en stock, accepter la commande puis passer votre propre commande pour la différence plus 20%, et ainsi vous écrirez cette logique métier (flux) .
CRUD récupère et modifie simplement les données dans le stockage. La logique métier détermine ce que vous faites avec ces données et les transformations que vous êtes autorisé à y apporter. Votre client est né dans le futur, âgé de moins de 5 ans, d'une certaine zone géographique (réductions pour les locaux/visiteurs). CRUD est simple, sachant que vous ne pouvez obtenir un crédit d'impôt pour enfants que si l'enfant a vécu avec vous pendant plus de la moitié du temps où il était en vie au cours de l'année civile PAS seulement pendant plus de 6 mois, est plus complexe.
La logique ou les règles métier sont tout ce qui ne pas se rapporte à la mécanique de l'interface utilisateur (le "truc de programmation"). Ce sont les choses que vous auriez encore à appliquer si vous faisiez cette transaction ou autre il y a 100 ans (manuellement). Par exemple, quand appliquer la taxe de vente à un achat.
La "logique métier" d'un programme ou d'une application est la partie du code qui fait réellement les choses avec une entrée (de l'utilisateur, du système d'exploitation, etc.). Les "règles métier" d'une application sont généralement les paramètres définis du programme lui-même (comme la façon de gérer les entrées). C'est du moins ce que j'ai entendu dire par de nombreuses personnes. Ce sont des termes assez similaires pour décrire des parties du code.