book

Transformation axée sur le domaine (French Edition)

Name: Transformation axée sur le domaine (French Edition)
ISBN: 0642572288679

by Carola Lilienthal, Henning Schwentner

December 2025

Intermediate to advanced

464 pages

12h 40m

French

O'Reilly Media, Inc.

Read now

Unlock full access

Avant-propos
Préface
Structure de cet ouvrageTransformation assistée par l'IAConventions utilisées dans ce livreApprentissage en ligne O'ReillyComment nous contacterRemerciements
1. Introduction : la transformation orientée domaine en bref
Exemple : un système existant dans un port à conteneursRedécouverte du domaineDéterminer l'architecture cibleComparer l'architecture actuelle avec l'architecture ciblePriorisation et mise en œuvre de la transformationQue vient-il de se passer ?La méthodeParcours à travers la transformation axée sur le domaineRésumé
I. Principes fondamentaux
2. Maîtriser la complexité
Origine de la complexité : espace des problèmes et des solutionsType de complexité : essentielle ou accidentelleSources de complexité accidentelleDomaines de décision de l'architecture logicielleGérer la complexité essentielle et accidentelleLa complexité dans les systèmes existantsLes méthodes de baseEt après ?
3. Conception orientée domaine
Concepts DDD contre la complexitéDDD et le domaine métierLangage omniprésentConception stratégique du côté commercialCatégorisation des sous-domaines : qu'est-ce qui est essentiel ?DDD et la solution logicielleConception stratégique dans le logicielCartographie du contexteContexte bulleLe modèle de domaineL'architecture en couches dans le DDDConception tactiqueÉvénements de domaineRésumé
4. Modélisation collaborative
Outils de modélisation et monopole du modèleMéthodes de modélisation collaborative pour la transformationRassembler les bonnes personnesConcepts de base de la modélisation collaborativeModélisation collaborative et DDDRécits de domaineUne image, une histoireDéfinir les limitesFacteurs de portée pour les récits de domaineTrouver le modèle de domainePerspectivesEventStormingExplorer avec une vue d'ensemble EventStormingExploration chaotiqueRespecter le calendrierPersonnes et systèmesPrésentation claireÉtapes à valeur ajoutéeFixer des limitesLe code couleurPlus en détail : conception de logiciels EventStormingTrouver le modèle de domaineAutres formats et perspectivesCasting de scénariosComment ça marche ?L'idée de baseDéroulement de l'atelier : de l'exploration à la mise en œuvrePrésentation d'une étude de cas : Green Urban SupplierÉtape 1 : Remue-méningesÉtape 2 : se concentrerÉtape 3 : AssemblageQuelle est la prochaine étape de l'approche basée sur des scénarios ?Deuxième tour de casting de scénariosPerspectivesQuelle méthode utiliser quand ?Modélisation collaborative à distanceModélisation collaborative et IAAutres méthodes de modélisation collaborativeRésumé
5. Concepts de l'architecture logicielle
Documentation de l'architecture avec le modèle C4Niveau 1 : ContexteNiveau 2 : ConteneursNiveau 3 : ComposantsNiveau 4 : CodeModularitéCohésion et couplageCohésion et couplage dans le DDDCohésion et couplage dans le domaineBig Ball of MudAu niveau de la classeAu niveau de l'architectureD'où vient la grosse boule de boue ?Couplage et réutilisationStyles architecturaux pour les systèmes existantsMonolitheMicroservicesDu monolithe aux microservicesLa bonne vieille architecture en couchesArchitectures internes-externes : hexagonales/ports et adaptateurs, oignon, propres, et plus encoreDifférents styles ensemble — Architecture expliciteArchitectures internes-externes et DDD tactiqueArchitecture logicielle HamburgerArchitectures orientées servicesSystèmes autonomesDes paysages informatiques à la SOA, et vice versaL'indice de maturité de la modularité : où en es-tu ?Modularité dans le MMIHiérarchie dans le MMICohérence des modèles dans le MMICalcul du MMIRésumé
6. Comment s'y prendre pour la transformation
Remplacement — Big BangRemplacement — étape par étapeRemaniementRésumé
II. Transformation axée sur le domaine technique, tactique et organisationnel de l'équipe

7. Stabilisation technique des logiciels existants
Mise à jour de l'environnement de développement intégréAutomatisation de la compilation et du déploiementMettre à jour les dépendances logiciellesMise à jour des bibliothèques et des frameworksMettre à jour le langage de programmationRésolution des avertissements du compilateur et de l'IDEAugmenter la couverture des tests lors de la correction des boguesLa règle du scout (avant, on l'appelait la règle du boy-scout)Différents types de testsNettoyage du code au fur et à mesureRefactoringBriser les dépendancesAméliorer la structure interne à l'aide de métriquesAméliorer la robustesse face aux erreursRenforcer la robustesse contre les valeurs nullesMieux utiliser les exceptionsIntroduire la conception par contratRésuméOù en êtes-vous ? — Simplifié
8. Renforcer le code source avec des connaissances du domaine
Séparer le code source métier et le code source techniqueAugmenter la cohésionEnrichir la modélisation avec des connaissances du domaineUtiliser des objets de valeurIntroduire la conception par contratRendre l'identité des entités plus claireRéduire le couplageBriser les cycles et les dépendancesIntroduire des références d'identifiant aux limites des agrégatsRéduire l'héritage dans le code source métierLe principe de substitution de LiskovDocumenter l'architecture dans le codeL'IA connaît-elle mon domaine ?RésuméOù en êtes-vous ? — Simplifié
9. Amélioration de l'organisation de l'équipe
Le logiciel en tant que système sociotechniqueArchitecture horizontale/organisation des équipesArchitecture verticale/organisation des équipesComment faire cette réorganisation d'équipe ?Topologies d'équipeTravailler dans le fluxTypes de topologiesModes d'interaction des équipesÉvolution de l'équipe au fil du tempsModernisation de l'architecture Équipes habilitantesRésuméOù en es-tu ? — Simplifié
III. Transformation stratégique axée sur le domaine
10. Étape 1 — Redécouverte du domaine
Description schématique de l'étape 1Défi : trouver les bons experts dans le domaineDéfi : diriger les experts du domaine Retour au domaine réelSous-étape 1.1 : Apprendre à connaître la situation actuelleSous-étape 1.2 : Extraire les connaissances du domaine (purification)Technique : expérience de réflexion « processus papier »Technique : expérience de réflexion « acteurs virtuels »Alternative : modélisation pure dès le départDistiller un langage omniprésentSous-étape 1.3 : Optimiser les processus métierSous-étape 1.4 : Trouver des sous-domaines dans les processus métierIndicateurs pour les limites des sous-domainesDéfi : ne pas décomposer par tâchesDéfi : trouver la bonne tailleObjectifs de la bonne tailleIndicateurs pour la bonne tailleDiscuter de la décomposition avec l'IARésumé
11. Étape 2 — Modélisation de l'architecture cible orientée domaine
Description schématique de l'étape 2Sous-étape 2.1 : Créer une carte contextuelleDéfi : contextes induits par l'espace de solutionsSous-étape 2.2 : Classer les sous-domainesSous-étape 2.3 : Attribuer des contextes délimités aux équipesDéfi : assigner des équipes, c'est souvent les formerSous-étape 2.4 : Déterminer les relationsTout mettre en placeRésumé
12. Étape 3 — Aligner l'architecture actuelle sur l'architecture cible
Description schématique de l'étape 3Sous-étape 3.1 : Identifier l'architecture réelleArchitecture réelle et IASous-étape 3.2 : Comparer la carte contextuelle cible et le code sourceDéfi : modèles illimitésDécomposition de l'intérieur vers l'extérieurDéfi : le modèle de domaine illimitéProblème : mauvaise compréhension de la réutilisabilitéDéfi : le modèle de domaine anémique illimitéDéfi : le modèle de données illimitéDéfi : décomposer l'interface utilisateurInterface utilisateur monolithiqueInterface utilisateur dans son contexte : microfrontendsSous-étape 3.3 : Compiler les refactorisations et les conclusionsRésumé
13. Étape 4 — Hiérarchisation et mise en œuvre des mesures de transformation
Description schématique de l'étape 4Sous-étape 4.1 : Choisir la première refactorisation stratégiqueModèle : commencer par un sous-domaine de soutienModèle : continuez avec un domaine centralSous-étape 4.2 : Ajouter des refactorisations tactiques au backlog du produit (ou au backlog d'amélioration)Sous-étape 4.3 : Planifier les refactorisations réalisables dans le backlog du sprintNe faire une pause dans la refonte qu'en cas d'urgenceEstimer les refactorisationsTransformation axée sur le domaine avec KanbanSous-étape 4.4 : Extraire le contexteDéfi : démêler la logique métier dans les servicesDéfi : déplacer les données locales, les setters et les getters dans un contexteIdentité des entitésDéfi : dupliquer les données, les setters et les getters dans plusieurs contextesDéfi : introduire des événements de domaine entre les servicesDéfi : déplacer la logique de domaine hors des services et dans le modèle de domaine anémiqueTransférer la logique des services vers des entités anémiquesDéfi : démêler le modèle de donnéesDéfi : choisir les résultats au bon momentDéfi : garder l'enduranceRésumé
IV. Conclusion
14. Perspectives : modèles de domaine et leur mise en œuvre dans des contextes délimités
Dimension 1 : flux de travail dans le domainePipeline de modèles de domaineTableau noir des modèles de domaineBoîte de dialogue des modèles de domaineÉvolution des domaines et des modèles qu'ils suiventDimension 2 : le modèle de domaine dans le logicielÉlément de domaine central par rapport à éléments de domaine diversModèle de domaine basé sur les formulairesDimension 3 : Forme du domaineÂge et maturité du domaineDomaine des objets tangibles vs domaine entièrement numériséPossibilités de transformationRésumé
15. Résumé de la transformation axée sur le domaine
A. Aperçu du catalogue des refactorisations axées sur le domaine
B. Refactorisations stratégiques
Extraire le contexte délimitéMotivationMécanismesImplémenter le contexte délimité à partir de zéroMotivationMécanique
C. Refactorisations tactiques qui soutiennent les refactorisations stratégiques
Extraire le service spécialiséMotivationMécaniqueExtraire l'entité spécialiséeMotivationMécaniqueExtraire une entité anémique spécialiséeMotivationMécaniqueExtraire une table spécialiséeMotivationMécanismes de mise à jour des schémasMécanique de la migration des donnéesMécanismes du programme d'accès
D. Refactorisations sociotechniques
Former une équipe interfonctionnelle à partir des membres de l'équipe de coucheMotivationMécanismesFormer une deuxième équipe interfonctionnelle avec des membres de l'équipe de couche et de la première équipeMotivationMécanismesFormer une deuxième équipe avec seulement les membres de l'équipe de coucheMotivationMécanique
E. Refactorisations tactiques qui renforcent la connaissance du domaine
Appliquer un langage communMotivationMécaniqueRemplacer les primitives par des objets de valeurMotivationMécaniqueGuérir l'anémie des entitésMotivationMécaniqueRemplacer le setterMotivationMécaniqueSupprimer le setterMotivationMécaniqueDéplacer la logique du service vers l'entitéMotivationMécaniqueIntroduire un contratMotivationMécaniqueDiviser l'enregistrement actif en agrégat et référentielMotivationMécaniqueDiviser le référentiel en interface et implémentationMotivationMécaniqueExtraire l'entité de l'interface utilisateur intelligenteMotivationMécaniqueExtraire le service de l'interface utilisateur intelligenteMotivationMécanique
Bibliographie
Index
À propos des auteurs

Content preview from Transformation axée sur le domaine (French Edition)

Annexe C. Refactorisationstactiques qui soutiennent les refactorisations stratégiques

Les refactorisations stratégiques d's sont toujours importantes et doivent être divisées en étapes plus petites. Dans cette annexe, on présente ces étapes plus petites, c'est-à-dire les refactorisations tactiques qui soutiennent les refactorisations stratégiques. Une refactorisation tactique de soutien est toujours effectuée dans le cadre d'une refactorisation stratégique.

Quand on extrait un contexte délimité, on peut se retrouver dans différentes situations :

Un modèle de domaine anémique. Dans ce cas, Extraire une entité anémique spécialisée et Extraire un service spécialisépeuvent t'aider.
Un modèle de domaine avec un comportement riche. Ça peut être divisé avec Extrait d'entité spécialisée et avec Extract Specialized Service.
Un modèle de données monolithique. On peut le traiter avec Table spécialisée d'extraction.

Service spécialisé d'extraction

Aussi appelé : « Carve Specialized Anemic Service Out of Monolithic Service »

Un cas particulier de Extraction de classe [Fowler 2019, p. 182]

Diagram illustrating the "Extract Class" refactoring pattern by splitting the "Monolease" class's "ContractService" functions into two separate classes, retaining "vote()" in "Monolease" and moving "calculateInstallment()" and "sign()" to "offering".

Raison

Comme , une étape de Extraction du contexte délimité, tu as trouvé un service de domaine qui est devenu trop gros. Ses fonctionnalités appartiennent en partie au contexte délimité qui est extrait. La décision a été prise de le diviser.

Mécanique

Crée une nouvelle classe vide dans le ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Mise en service et optimisation des LLM par la pratique (French Edition)

Publisher Resources

ISBN: 0642572288679

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business