Je travaille avec le développement Web depuis 2009, quand j'ai commencé avec PHP. Lorsque j'ai migré vers ASP.NET, j'ai beaucoup entendu parler de DDD et de OOAD, qui accordent une grande importance à cette "logique métier" et à ces "règles commerciales". Le fait est que toutes les applications que j'ai développées jusqu'à présent portaient toutes sur les opérations CRUD et que je n'ai jamais vu cela 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 ces méthodes sont implémentées en tant que méthodes dans les modèles de domaine, mais que pourraient-elles être et quelles applications pourraient-elles utiliser?

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 les applications métier ne se limitent pas à la création, la lecture, la mise à jour et la suppression 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 aux logiciels réels.

La logique métier ou la logique de domaine est la partie du programme qui code les règles métier du monde réel qui déterminent la manière dont les données peuvent être créées, stockées et modifiées. Il spécifie comment les objets métier interagissent les uns avec les autres et applique les itinéraires et les méthodes permettant d'accéder aux objets métier et de les mettre à jour.

Les règles de gestion décrivent les opérations, les définitions et les contraintes qui s'appliquent à une organisation. Les opérations forment collectivement un processus; chaque entreprise utilise ces processus pour former des systèmes permettant d'accomplir des tâches.

Maintenant, travaillons avec quelques exemples.

Transférer de l'argent d'un compte à un autre

Premièrement, quelles sont les choses que vous devez savoir (entrée)?

• Identité de la personne effectuant le transfert
• Le montant d'argent à transférer
• Le numéro de compte chèque source
• Le numéro de compte chèque cible

Quelles sont certaines des "règles de gestion" 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 être soumise à des obligations de déclaration auprès du gouvernement, si elle dépasse un certain montant.

Par "atomique", j'entends que la transaction doit réussir complètement ou échouer complètement. Vous ne pouvez pas avoir de transactions de compte dans lesquelles l'argent est retiré d'un compte sans arriver dans l'autre (l'argent disparaît), ou l'argent est déposé dans un compte, mais non débité d'un autre compte (l'argent apparaît comme par magie de nulle part).

Commander quelque chose sur Amazon.

Que veux-tu savoir?

• L'identité de la personne qui commande
• Informations sur la livraison
• Détails de facturation
• Moyen de paiement
• Quantité et quantité de chaque article à expédier
• Comment expédier (nuit, bateau lent ou super épargnant)
• Taux d'imposition de l'État

Que se passe-t-il après la commande?

• Les articles sont tirés du stock
• Les quantités en main 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 tombent au-dessous des quantités minimales sont commandés
• Une expédition ou deux?

• Une liste de facturation / d'expédition est imprimée et placée avec la commande

  ..etc.

CRUD est simplement créer, lire, mettre à jour, supprimer par une application.

Dans une certaine mesure, un traqueur de bogues est également une application CRUD. Créez des bogues, lisez (affichez) les bogues, mettez-les à jour et, éventuellement, supprimez-les.

Cependant, un traqueur de bogues ne se limite pas à CRUD.

• Un développeur n'est pas autorisé à marquer le bogue vérifié ou fermé - cela fait partie du travail de QA. Et donc, du code est là pour s'assurer que quelqu'un à qui le rôle d'AQ n'est pas assigné ne peut pas marquer un bogue comme étant fermé ou vérifié.
• Personne d'autre qu'un chef de projet ne peut réellement supprimer un bogue.
• Pour qu'un bogue soit marqué comme "testez-moi", il doit y avoir au moins un commit 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"
• L'assurance 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 flux de travail, ou qui peut faire les différentes opérations dans CRUD. Ce sont ce qui sépare une application CRUD d'un autre. Ce sont les parties sur lesquelles vous devez amener l’entreprise à dire réellement comment fonctionne l’application. Comme c'est logique ... eh bien, c'est mieux de discuter autour d'une bière hors de la portée de l'oreille du gestionnaire de projet. Mais c’est ce que la logique commerciale est.

Bien sûr, il est possible d'écrire une application «pure» CRUD où il n'y a pas de rôles, tout peut être modifié et visualisé - 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 à être à un niveau plus élevé que la simple logique ou la logique métier. Cela a tendance à être ce que vous obtenez d'un analyste commercial qui travaille avec l'entreprise.

Considérons dans cet exemple, un programme qui détermine comment gérer le retour d'un article à un comptoir de retour 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 récépissé date de moins de 90 jours, créditez l'offre avec laquelle il a été utilisé (le crédit revient sur la carte de crédit, l'argent revient en espèces, le crédit en magasin va au crédit en magasin) ... sauf si était un chèque, auquel cas utiliser de l'argent.

Ce sont des règles commerciales. Ils ne parlent pas de la partie CRUD de l'application.

Lorsque vous travaillez avec des règles métier, celles-ci peuvent souvent être écrites dans un moteur de règles (par exemple, le moteur de règles Windows Workflow Foundation ) au lieu d'écrire le code brut dans votre système.

Sachez que la distinction entre logique et règles est d'ordre terminologique et peut être discutée toute la nuit (encore mieux avec une bière). Bien que ce ne soit pas une distinction peu commune, bien que les deux puissent se fondre l'un dans l'autre.

Les 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, par exemple, passer de Turbo Pascal à Java , la logique et les règles commerciales correspond à ce que l'ancien projet et le nouveau projet auraient en commun .

Le langage de programmation serait différent. Le code source serait entièrement différent. Les outils ( IDE , 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 accompli / des objectifs accomplis, serait le même.

La logique métier comprend essentiellement deux grandes catégories: la validation et le flux. La logique applicative indique 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 commerciale et vous écrivez donc du code pour appliquer cette logique métier (validation). Une autre application indiquera 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 vous écrirez donc cette logique métier (flux). .

CRUD consiste simplement à importer et à modifier des données et à les modifier. La logique applicative détermine ce que vous faites avec ces données et les transformations que vous êtes autorisé à y apporter. Votre client est-il né à l'avenir, moins de 5 ans, d'une certaine zone géographique (réductions pour les habitants / 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é de sa vie au cours de l’année civile.

La logique métier ou les règles sont tout ce qui ne concerne pas la mécanique de l'interface utilisateur (le "truc de programmation"). Ce sont les choses que vous auriez toujours à appliquer si vous réalisiez cette transaction ou quoi que ce soit 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 les choses avec les entrées (de l'utilisateur, du système d'exploitation, etc.). Les "règles de gestion" d'une application sont généralement les paramètres définis du programme lui-même (par exemple, comment gérer les entrées). C'est du moins ce que j'ai entendu dire par beaucoup de gens. Ce sont des termes assez similaires pour décrire des parties du code.