book

Apprendre la conception pilotée par les domaines

by Vlad Khononov

November 2024

Intermediate to advanced

342 pages

9h 39m

French

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

Pourquoi j'ai écrit ce livreQui devrait lire ce livre ?Naviguer dans le livreExemple de domaine : WolfDeskConventions utilisées dans ce livreUtiliser des exemples de codeApprentissage en ligne O'ReillyComment nous contacterRemerciements
Qu'est-ce qu'un domaine commercial ?Qu'est-ce qu'un sous-domaine ?Types de sous-domainesComparaison des sous-domainesIdentifier les limites des sous-domainesExemples d'analyse de domaineGigmasterBusVNextQui sont les experts du domaine ?ConclusionExercices
Problèmes professionnelsDécouverte des connaissancesCommunicationQu'est-ce qu'une langue omniprésente ?Langue de l'entrepriseScénariosCohérenceModèle du domaine d'activitéQu'est-ce qu'un modèle ?Une modélisation efficaceModélisation du domaine d'activitéEffort continuOutilsLes défisConclusionExercices
Modèles incohérentsQu'est-ce qu'un contexte délimité ?Limites du modèleRaffinement du langage omniprésentPortée d'un contexte délimitéContextes délimités et sous-domainesSous-domainesContextes limitésL'interaction entre les sous-domaines et les contextes délimitésLimitesLimites physiquesLimites de propriétéDes contextes limités dans la vie réelleDomaines sémantiquesLa scienceAcheter un réfrigérateur ConclusionExercices
CoopérationPartenariatNoyau partagéClient-FournisseurConformisteCouche anticorruptionService d'hébergement ouvertDes chemins séparésQuestions de communicationSous-domaines génériquesDifférences entre les modèlesCarte du contexteEntretien LimitesConclusionExercices
Script de transactionMise en œuvreCe n'est pas si facile !Quand utiliser le script de transactionDossier actifMise en œuvreQuand utiliser l'enregistrement actifSois pragmatiqueConclusionExercices

HistoireModèle de domaineMise en œuvreBlocs de constructionGérer la complexité ConclusionExercices
Sourcing d'événementsRechercheAnalyseSource de véritéMagasin d'événementsModèle de domaine basé sur les événementsAvantagesInconvénientsQuestions fréquemment poséesPerformanceSuppression des donnéesPourquoi ne puis-je pas simplement... ?ConclusionExercices
Logique commerciale et modèles architecturauxArchitecture en couchesCouche de présentationCouche logique d'entrepriseCouche d'accès aux donnéesCommunication entre les couchesVariationQuand utiliser l'architecture en couchesPorts et adaptateursTerminologiePrincipe d'inversion de la dépendanceIntégration des composants de l'infrastructureVariantesQuand utiliser les ports et les adaptateursSéparation des responsabilités entre les commandes et les requêtesModélisation polyglotteMise en œuvreProjeter les modèles de lectureLes défisModèle de ségrégationQuand utiliser le CQRSChamp d'applicationConclusionExercices
Traduction du modèleTraduction de modèle sans étatTraduction de modèle avec étatIntégrer des agrégats Boîte d'envoi SagaGestionnaire de processusConclusionExercices
HeuristiqueContextes limitésModèles de mise en œuvre de la logique d'entrepriseModèles architecturauxStratégie de testPyramide de testTest du diamantPyramide de test inverséeArbre de décision de la conception tactiqueConclusionExercices
Changements dans les domainesDe l'essentiel au génériqueDu générique à la baseSoutien aux génériquesSoutien à la baseDe la base au soutienDu générique au soutienPréoccupations stratégiques en matière de conceptionPréoccupations en matière de conception tactiqueTransaction Script to Active RecordActive Record to Domain Model (enregistrement actif au modèle de domaine)Modèle de domaine à modèle de domaine à source événementielleGénérer des transitions passéesModélisation des événements migratoiresChangements organisationnelsPartenariat client-fournisseurLe client et le fournisseur s'éloignent l'un de l'autreConnaissance du domaineCroissanceSous-domainesContextes limitésAgrégatsConclusionExercices
Qu'est-ce que l'EventStorming ?Qui devrait participer à EventStorming ?De quoi as-tu besoin pour l'EventStorming ?Le processus d'EventStormingÉtape 1 : Exploration non structuréeÉtape 2 : DélaisÉtape 3 : Points douloureuxÉtape 4 : Événements décisifsÉtape 5 : CommandesÉtape 6 : PolitiquesÉtape 7 : Lire les modèlesÉtape 8 : Systèmes externesÉtape 9 : AgrégatsÉtape 10 : Contextes délimitésVariantesQuand utiliser EventStormingConseils d'animationRegarde la dynamiqueÉvénement à distanceTourbillonConclusionExercices
Analyse stratégiqueComprendre le domaine d'activitéExplore la conception actuelleStratégie de modernisationModernisation stratégiqueModernisation tactiqueCultiver une langue omniprésenteConception pragmatique pilotée par les domainesVendre la conception pilotée par les domainesConception guidée par les domaines sous couvertureConclusionExercices
Qu'est-ce qu'un service ?Qu'est-ce qu'un microservice ?Méthode en tant que service : Des microservices parfaits ?Objectif de conceptionComplexité du systèmeLes microservices en tant que services profondsLes microservices en tant que modules profondsConception pilotée par le domaine et limites des microservicesContextes limitésAgrégatsSous-domainesCompression des interfaces publiques des microservicesService d'hébergement ouvertCouche anticorruptionConclusionExercices
Architecture pilotée par les événementsÉvénementsÉvénements, commandes et messagesStructureTypes d'événementsConception d'une intégration pilotée par les événementsGrande boule de boue distribuéeCouplage temporelCouplage fonctionnelCouplage de mise en œuvreRefonte de l'intégration pilotée par les événementsHeuristique de conception pilotée par les événementsConclusionExercices
Modèle de données analytiques versus modèle de données transactionnellesTableau des faitsTableau des dimensionsModèles analytiquesPlateformes de gestion des données analytiquesEntrepôt de donnéesLac de donnéesDéfis des architectures d'entrepôt de données et de lac de donnéesData MeshDécomposer les données autour des domainesLes données en tant que produitPermettre l'autonomieConstruis un écosystèmeCombiner le Data Mesh et la conception pilotée par les domaines.ConclusionExercices
ProblèmeSolutionMise en œuvrePour en savoir plusConception avancée pilotée par les domainesModèles d'architecture et d'intégrationModernisation des systèmes existantsEventStormingConclusion
Cinq contextes limitésDomaine d'activitéContexte délimité #1 : MarketingContexte limité #2 : CRMContexte limité #3 : Croqueurs d'événementsContexte limité #4 : BonusContexte délimité #5 : La plaque tournante du marketingDiscussionLangage omniprésentSous-domainesLimites des contextes limitésConclusion
Chapitre 1Chapitre 2Chapitre 3Chapitre 4Chapitre 5Chapitre 6Chapitre 7Chapitre 8Chapitre 9Chapitre 10Chapitre 11Chapitre 12Chapitre 13Chapitre 14Chapitre 15Chapitre 16

Content preview from Apprendre la conception pilotée par les domaines

Chapitre 4. Intégrer des contextes limités

Cet ouvrage a été traduit à l'aide de l'IA. Tes réactions et tes commentaires sont les bienvenus : translation-feedback@oreilly.com

Non seulement le modèle de contexte délimité protège la cohérence d'un langage omniprésent, mais il permet également la modélisation. Tu ne peux pas construire un modèle sans spécifier son but - sa limite. La frontière divise la responsabilité des langages. Dans un contexte délimité, un langage peut modéliser le domaine de l'entreprise pour résoudre un problème particulier. Un autre contexte délimité peut représenter les mêmes entités commerciales mais les modéliser pour résoudre un problème différent.

De plus, les modèles dans différents contextes délimités peuvent être évolués et mis en œuvre de manière indépendante. Cela dit, les contextes délimités eux-mêmes ne sont pas indépendants. Tout comme un système ne peut pas être construit à partir de composants indépendants - les composants doivent interagir les uns avec les autres pour atteindre les objectifs globaux du système - il en va de même pour les implémentations dans les contextes délimités. Bien qu'elles puissent évoluer indépendamment, elles doivent s'intégrer les unes aux autres. Par conséquent, il y aura toujours des points de contact entre les contextes délimités. Ces points sont appelés contrats.

La nécessité de conclure des contrats résulte des différences entre les modèles et les langages des contextes délimités. Comme chaque contrat concerne ...