Présentation
Je voudrais parler de l'expérience de l'application des pratiques DDD à un projet Ruby on Rails existant. Au départ, nous avions un monolithe écrit pendant 10 ans. La principale difficulté du projet résidait dans des processus assez complexes et une connectivité élevée. Nous avons réussi non seulement à décomposer l'application en services séparés, mais aussi à augmenter considérablement la lisibilité du code, à rendre les processus décrits transparents.
La résolution de problèmes au sein du système est devenue prévisible, nous avons cessé de travailler avec la boîte noire et, finalement, le système lui-même a commencé à nous proposer des solutions.
Pour faciliter à la fois la perception et l'écriture, une histoire sur les approches utilisées sera présentée sous forme d'une série d'articles. Cette approche n'est pas une «solution miracle», je voudrais donc souligner tout d'abord le segment de projets auquel cette solution peut répondre. De plus, je parlerai plus en détail de la méthodologie DDD et de l'implémentation de microservices de ce modèle, je décrirai les combinaisons possibles des modèles appliqués en tenant compte de leur implémentation et, finalement, je donnerai un exemple d'implémentation spécifique d'un petit service.
Thésaurus
Le thésaurus est un glossaire de termes utilisés pour décrire un domaine spécifique.
Toutes les définitions qui seront introduites ci-dessous sont correctes dans le cadre de cet article. Vous pouvez les appliquer à votre sujet s'ils le décrivent assez bien.
Le problème résolu dans le cadre de cette approche
L'approche décrite ci-dessous a une spécialisation assez étroite et vise avant tout à résoudre un problème spécifique. Néanmoins, cela n'exclut pas l'intérêt possible de spécialistes dans des domaines connexes. Donc, nous avons la tâche:
Vous devez réécrire et gérer un projet avec une logique métier complexe écrite en Ruby on Rails, avec des ressources suffisantes.
Écrivons cette tâche plus en détail.
Pourquoi est-il nécessaire de réécrire le projet?
Je pense que chaque développeur peut répondre à cette question. Il est plus difficile de répondre pour que cette réponse réponde aux besoins de votre entreprise.
Nous utilisons la définition de l' entreprise , telle qu'elle est généralement acceptée, bien que nous investissions dans ce terme un concept plus large - une entreprise (quelque chose entrepris par un groupe de personnes), une occupation (occupée).
L'entreprise est l'effort d'une entreprise de personnes, exprimée par des actions visant à obtenir des avantages pour un large éventail de personnes.
Par exemple:
- L'entreprise fabrique un produit pour les consommateurs ou fournit un service.
- Le laboratoire développe un nouveau médicament.
- L'école est engagée dans la formation.
- Les archives de la ville fournissent des informations aux citoyens.
- Lera fait plaisir à ses fans avec une excellente figure sur le réseau social.
Dans le cas de masse, une entreprise se construit autour de l'idée de réaliser un profit en satisfaisant les besoins de ses clients. Afin d'augmenter le profit, il est nécessaire de satisfaire les besoins réels du client avec un grand nombre de solutions de qualité. Cette idée est décrite comme le premier principe du manifeste Agile, bien que l'idée ne soit pas nouvelle. Le fait que les besoins sous-tendent notre société a été soutenu par de nombreux philosophes. Par exemple, Platon a essayé de rationaliser les besoins, de créer leur classification. C'est lui qui nomme les principales formes de besoins économiques: nourriture, habillement, logement. "Le défi des entreprises" est de satisfaire les besoins. Et les solutions appliquées devraient accroître la compétitivité de l'entreprise.
Compétitivité - L'avantage d'une entreprise sur une autre.
Le manifeste Agile nous donne également une indication que la flexibilité du projet est renforcée par son excellence technique et sa qualité de conception.
Considérons la chaîne d'approvisionnement des valeurs sur l'exemple d'un «projet Web typique»
- t 0 - nous avons une idée.
- t 1 nous avons implémenté MVP . Ici, nous nous éloignons un peu:
Produit viable minimum MVP - un produit qui a les fonctions minimales, mais suffisantes pour satisfaire les premiers consommateurs. La tâche principale est d'obtenir un retour d'information pour la formation d'hypothèses pour le développement futur du produit.
Le terme a été popularisé par Steve Blank et Eric Rees. MVP est un outil efficace pour tester votre idée d'entreprise et répondre à la question principale "Décoller - ne décollera pas?"
- t 2 - Retour au planning. L'idée a été couronnée de succès, nous avons reçu des commentaires positifs et avons pu satisfaire un grand nombre de besoins des clients au moment indiqué.
- t 3 - Cette fois, la satisfaction est venue dans une moindre mesure. Nous avons augmenté le personnel.
- t 4 - Nous avons livré encore moins de valeurs.
- t 5 - Si nous n'avons pas commencé le refactoring, alors à ce stade, l'entreprise cesse d'être compétitive.
Pourquoi cela se produit-il? Au fil du temps, notre projet accumule un haut niveau d'entropie en raison de sa connectivité élevée. Supposons que nous ayons une «entreprise type» composée d'un service de marketing, d'analyse, de logistique, de vente et de gestion. Pour le moment, le projet est le suivant:
Je voudrais immédiatement faire une réservation que la connectivité n'est pas toujours la cause de l'entropie, mais elle survient si un système avec un grand nombre de processus métier complexes est mis en œuvre.
L'entropie dans le code se produira toujours si les processus commerciaux de l'entreprise ne sont pas correctement formés. Ce qui peut être caractéristique des deux jeunes entreprises, qui sont au début de leur parcours, l'est aussi des grandes entreprises, où il est impossible de tout systématiser à la fois. C'est un processus naturel et nous ne devons pas nous opposer à lui, mais l'accepter et l'utiliser. Revenons au premier graphique et regardons-le de l'autre côté:
L'intégrale (la zone sous la ligne) sera l'argent gagné. La vraie application (Real app) gagnera plus que «l'idéal» (Academin app), au moins jusqu'au début de l'entropie - t 4 . Cela sonne bien et c'est ce que vous devez faire.
Mais que faire à l'avenir? Répéter le refactoring à l'infini est impossible. À un moment donné, le volume de la base de code atteindra un niveau tel qu'il sera difficile de réécrire «tout à la fois». Et tôt ou tard, il est nécessaire de diviser le projet en composants séparés:
Une approche pour la mise en œuvre de systèmes complexes est DDD:
La conception pilotée par domaine (DDD) est une approche du développement de logiciels pour la satisfaction complexe des besoins, en liant étroitement la mise en œuvre avec les principaux modèles commerciaux qui sont en constante évolution.
DDD est une série de pratiques et de définitions qui seront décrites plus en détail dans le prochain article. Le modèle central de cette approche est le contexte délimité , dont l'essence est que chaque sujet se compose de plusieurs ensembles de modèles qui ne devraient pas communiquer avec le monde extérieur, ainsi que de modèles utilisés dans le monde extérieur en conjonction avec d'autres contextes limités. Chaque contexte limité a une interface clairement définie où il décide quels modèles utiliser en conjonction avec d'autres contextes.
Ce modèle peut être implémenté via un espace de noms (espace de noms) et via des microservices. Nous utiliserons ces deux implémentations, selon le niveau de connectivité au contexte. Ce qui conduit finalement à la création d'une application décomposée et segmentée.
Il est peu probable que les graphiques ci-dessus reflètent l'image réelle, mais vous permettent de comparer différentes approches entre elles.
Support de projet
À l'appui du projet, un certain nombre de choses doivent être fournies.
- Livraison de valeur : Scrum, Agile, service client, livraison continue.
- Réduction d'entropie : DDD, Micro-service comme l'un des moyens de séparer les contextes, documentation.
- Qualité du code : conception au niveau du domaine, TDD, BDD.
- Qualité du produit : test manuel et automatisé, suivi des bogues, journalisation.
- Disponibilité du produit : systèmes de duplication.
- Vitesse du produit : mise à l'échelle horizontale.
- Rétention de l'équipe de développement : système de motivation, ouverture, honnêteté.
Comme vous pouvez le voir, la maintenance d'un système complexe nécessite une grande quantité de ressources. Tout d'abord, un personnel hautement qualifié. Avant d'utiliser telle ou telle technologie, demandez-vous si vous avez la possibilité d'apporter son soutien au bon niveau.
Il ne faut pas oublier que le seuil d'entrée dans un système complexe est assez élevé, il est donc important de former le personnel. De plus, si nous voulons travailler sans échecs, nous ne devons pas avoir de spécialistes "irremplaçables", et il est donc nécessaire d'assurer l'interchangeabilité totale de tous les rôles. Si vous avez un «spécialiste de la livraison continue» qui sort de l'équipe, vous devez le remplacer. Si le remplacement ne peut pas être fourni, il ne vaut pas la peine d'introduire la pile technologique dans la «production» sans fournir un soutien suffisant.
Il ne s'agit pas de spécialistes du même niveau. Laissez-vous avoir un leader DevOps et un certain développeur pour qui ce sujet est intéressant (le soi-disant "multiclasse"). Pour lui, comme pour le "second violon", il est important de bien comprendre où et comment trouver les outils pour résoudre le problème. Pour cela, au moins un quart du volume total des tâches entrantes liées à la nouvelle spécialité devrait lui être distribué. Ces tâches seront effectuées lentement, les coûts augmenteront, mais à l'avenir, cela évitera le risque d'interruption de la fourniture de valeurs en raison de pénuries de personnel.
De telles choses sont décrites dans les exigences de Scrum, je ne voudrais pas m'y attarder. La seule chose sur laquelle je voudrais attirer votre attention, ce à quoi vous devez vous préparer, ce sont les coûts importants qui seront dépensés pour soutenir votre projet. Si votre entreprise n'est pas prête pour cela et que vous avez commencé à utiliser de nombreux outils coûteux, vous ruinerez l'entreprise.
Brièvement
- Si vous devez implémenter MVP , commencez par Ruby On Rails.
- Si le MVP a décollé et que l'idée est justifiée, faites le premier refactoring, «allégez» vos modèles avec des services, des décorateurs, supprimez la couche de validation et de base de données des modèles dans des préoccupations distinctes. Rédiger des tests, de la documentation.
- Si vous n'avez pas un projet aussi complexe et que vous pouvez supprimer l'entropie en optimisant les modèles - faites-le.
- Si vous avez un projet logique et lisible, et que vous devez augmenter sa productivité, alors qu'il peut être divisé, par exemple, par les utilisateurs, alors utilisez la mise à l'échelle. Mais n'essayez pas de diviser le projet en services par domaine.
- Si vous avez une entreprise «complexe» et que vous recherchez un outil pour vous connecter à Internet (pourquoi ne l'avez-vous pas encore fait?!) - envisagez également des «solutions d'entreprise» prêtes à l'emploi, par exemple, en java ou .NET. Les pratiques décrites proviennent de ces solutions et elles disposent d'un riche ensemble d'outils prêts à l'emploi, ce qui vous fera économiser de l'argent.
- Si votre projet est sur ruby, vous avez une équipe de programmeurs ruby, le projet contient une logique métier complexe, se prépare au chargement ou est déjà chargé, et l'entropie a tellement augmenté qu'il est très, très difficile à réécrire, alors vous devriez envisager d'utiliser l'approche DDD et Microservices.
La prochaine fois, je voudrais examiner plus en détail l'essence de l'approche DDD et sa mise en œuvre de microservices.
Sources d'inspiration: