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 5. Mise en œuvre d'une logique commerciale simple

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

La logique d'entreprise est la partie la plus importante du logiciel. C'est la raison pour laquelle le logiciel est mis en œuvre en premier lieu. L'interface utilisateur d'un système peut être sexy et sa base de données peut être extrêmement rapide et évolutive. Mais si le logiciel n'est pas utile à l'entreprise, ce n'est rien d'autre qu'une démo technologique coûteuse.

Comme nous l'avons vu au chapitre 2, tous les sous-domaines commerciaux ne sont pas créés égaux. Les différents sous-domaines ont des niveaux d'importance stratégique et de complexité différents. Ce chapitre commence notre exploration des différentes façons de modéliser et d'implémenter le code de logique commerciale. Nous commencerons par deux modèles adaptés à une logique commerciale plutôt simple : le script de transaction et l'enregistrement actif.

Script de transaction

Organise la logique d'entreprise par des procédures où chaque procédure traite une seule demande de la présentation.

Martin Fowler¹

L'interface publique d'un système peut être considérée comme un ensemble de transactions commerciales que les consommateurs peuvent exécuter, comme le montre la figure 5-1. Ces transactions peuvent récupérer des informations gérées par le système, les modifier, ou les deux. Le modèle organise la logique commerciale du système ...