Get best of the week

Que puis-je apprendre sur la conception pilotée par domaine en 10 minutes?

Ils disent que vous pouvez sans cesse regarder le feu, observer le fonctionnement des autres et également étudier le DDD (Domain Driven Design, design spécifique au domaine). Mais si vous ne disposez que de 10 minutes, vous pouvez lire cet article et aller jusqu'au sommet, puis avec un look intelligent, hocher la tête lors d'un petit entretien.

Nous avons tordu et examiné DDD sous différents angles, en collaboration avec Andrei Ratushny, directeur technique d'Ugra Internet Solutions.





À propos de la société: Ugra Internet Solutions est une société qui se consacre à l'automatisation des processus commerciaux dans les secteurs commercial et public. Situé dans la ville de Khanty-Mansiysk. En développement 12 personnes.

1. Qu'est-ce que DDD, peut être expliqué même à un enfant (ou à un agent de commercialisation)


DDD est une approche qui vise à étudier le domaine de l'entreprise dans son ensemble ou tout processus métier individuel. Il s'agit d'une excellente approche pour les projets dans lesquels la complexité (complexité) de la logique métier est assez importante. Son utilisation est conçue pour réduire au maximum cette complexité.

En dehors de l'approche DDD, lorsqu'un programmeur écrit du code, il accorde plus d'attention aux technologies et à l'infrastructure, par exemple, comment envoyer un message, comment le recevoir, l'encoder, l'enregistrer dans une base de données, quelle base de données.

L'approche DDD suggère que tout cela, bien sûr, est important, mais secondaire. Les affaires sont plus importantes et devraient venir en premier. Et pour que tout cela fonctionne ensemble, DDD nous apprend (les développeurs) à parler le même langage avec les entreprises. Pas dans un langage de programmation, mais dans un langage d'affaires. Ceci est appelé dans le langage DDD ubiquitaire.

2. Puce DDD - Contexte délimité


Le contexte délimité est un outil DDD clé; c'est une frontière explicite à l'intérieur de laquelle existe un modèle de domaine. Il mappe une seule langue dans un modèle logiciel. C'est sur la base de contextes que vous pouvez diviser le code en modules / packages / composants afin que les changements dans chacun d'entre eux aient un effet minimal (ou nul) sur les autres.

Pour les développeurs, cette approche vous permet d'apporter des modifications au code sans craindre que quelque part dans un autre endroit quelque chose se casse (par exemple, changez quelque chose à la caisse et ne vous inquiétez pas que quelque chose tombera des courriers à cause de cela).

Pour les chefs d'équipe, cette approche nous permet de paralléliser considérablement le travail des équipes, ce qui peut accélérer considérablement le travail sur le projet.

Outre un contexte limité, il y a toutes sortes de choses comme les cartes de contexte, une seule langue, les relations entre les contextes, les cartes de traduction ... euhhh! Vous n'en parlerez pas en 10 minutes, mais vous pouvez lire le livre «vert».

3. Livres généraux sur DDD: rouge, bleu et vert


DDD est une approche assez ancienne. Son utilisation semble raisonnable et tout à fait justifiée, mais pour une raison quelconque, elle n'est toujours pas répandue, on en dit peu lors des conférences. Quel est le problème avec ce DDD?

On suppose que le principal problème est le manque de matériel de formation. Toute la théorie est décrite dans plusieurs livres: rouge , bleu et vert . Ils disent qu'il y a «un autre livre rouge» , mais peu l'ont encore vu :) Les

livres rouges et bleus sont si difficiles à percevoir que quelque part au milieu, je veux jeter le livre par la fenêtre en criant: «Assez de cette merde de moi, voyez ce DDD incompréhensible! Je vais faire ce que je peux. " Et cela ne concerne que la théorie, avec des documents sur la pratique, c'est encore plus compliqué.

Par conséquent, si vous décidez toujours de commencer à étudier la littérature sur DDD, il est préférable de commencer par un livre vert. Dans ce document, Vaughn Vernon parcourt les sommets de l'approche et, avec des exemples simples, montre ses avantages. Ils disent que la traduction s'est avérée douteuse, il est donc préférable de lire l'original.

4. Comment comprendre qu'il est temps d'appliquer DDD


Comptez le nombre de cas d'utilisation pour votre système. S'ils sont de l'ordre de 10 à 15, la logique métier n'est pas si compliquée et vous ne pouvez pas cuire à la vapeur, n'utilisez aucun DDD.

Si vous avez 30 à 50 cas UX ou plus, et qu'ils se croisent beaucoup, il est logique de penser à utiliser DDD au moins dans une partie du système.

5. Comment implémenter DDD dans l'entreprise de bas en haut


Imaginez que vous êtes un développeur qui aime DDD, et vous pensez que dans votre entreprise, cette approche peut être appliquée pour rendre les gens heureux.

Il est difficile de lancer une guérilla d'introduction de DDD seul. Premièrement, les connaissances peuvent ne pas être suffisantes pour démarrer le processus. Deuxièmement, les mecs de votre équipe peuvent penser que vous faites des choses stupides et vont tout casser en fourrant des bâtons dans les roues.

Il est préférable de commencer la mise en œuvre en créant un groupe d’initiative: essayez l’approche ensemble, comprenez les nuances et comprenez dans la pratique.

Ce n'est qu'alors que vous pouvez vous rendre chez un architecte ou un ingénieur technique pour lui en expliquer la valeur. Mais n'oubliez pas que DDD n'est pas nécessaire partout. DDD résout des problèmes spécifiques, il est donc très important de ne pas en faire trop.

L'approche a un effet secondaire: si les gens commencent même à lutter pour DDD, alors ils commenceront déjà à agir dans le paradigme de «Diviser, diviser, réduire la connectivité et suivre la logique métier». Et à partir de là, des changements positifs vont commencer: quelque part le code sera mieux écrit, quelque part la vitesse augmentera. Cette connaissance n'a pas à se transformer en code dans des contextes et autres artefacts DDD. Le code peut rester le code, mais il s'améliorera et la vitesse et la qualité augmenteront.

6. Comment implémenter DDD dans l'entreprise de haut en bas


  1. Assurez-vous que cette approche sera utile dans un cas particulier.
  2. Trouvez une personne dans l'équipe qui possède des compétences en architecture (il vous aidera à déterminer où dans le système les coutures doivent être coupées).
  3. Invitez des praticiens DDD à vous enseigner.
  4. . ! . , .

7. DDD


Bien sûr, grâce à la pratique. Ne dites pas à l'avance à la personne que vous lui enseignez le DDD, ne faites pas peur à l'avance.

Laissez la personne venir chercher les puzzles. Ne lui dites pas que c'est DDD, laissez-le faire. Il le fera en fonction de sa compréhension du solide et de tout cela. Puis, quand il remettra le travail, il devra dire: "Cher mec, ça semble marcher, mais ça doit être refait", et lui expliquer pourquoi.

Ne forcez pas à lire ou à apprendre tout à dessein. Soyez interactif à cet égard. Ainsi, une personne en 3-5 mois commencera à comprendre les principes de base du DDD: du point de vue de la mise en œuvre, du point de vue de la théorie. Il commencera à comprendre les modèles encore plus tôt par des artefacts d'approche - des cartes de contexte. Au début, les gens ne comprendront rien, mais progressivement ils seront coupés, et certains liront même des livres.

8. Je suis capable de DDD - une ligne sans importance pour le CV en Russie


Si vous êtes en Russie et connaissez DDD - c'est cool. Mais on est loin du fait que la connaissance du DDD lui-même soit utile dans le travail. Au contraire, il servira d'indicateur à l'employeur concernant votre niveau élevé de développement en tant que développeur. Après tout, les compétences que vous acquérez en étudiant l'approche DDD vous développent en tant que programmeur et concepteur (architecte).

Mais si vous songez à déménager à l'étranger, une telle ligne dans le CV peut avoir un impact positif. À l'étranger, la communauté DDD est beaucoup plus grande et l'approche elle-même est beaucoup plus populaire que la nôtre. Surtout en Europe.

9. La relation de DDD avec les poils du visage


Observation: Les personnes qui comprennent DDD portent une barbe. Est-ce à dire qu'avoir une barbe est une condition préalable au succès de DDD? Qu'est-ce que tu penses?

10. Documents utiles sur DDD



« ». , . , Miro, , Amazon, Microsoft, . .

:

More articles:


All Articles