Cet article a fait l'objet d'une traduction automatique.

Méthode conseillée

Introduction À création piloté par domaine

David Laribee

Cet article présente : Modélisation de langue omniprésents Délimitée contextes et regroupement racines À l'aide du principe de gestion unique Référentiels et bases de données

Cet article utilise les technologies suivantes : Visual Studio

Contenu

Le modèle Platonic
Communiquer avec le parler
Contexte
Connaître votre proposition de valeur
Un système de responsabilités unique
Entités ont des identités et une durée de vie
Objets de la valeur de décrire les éléments
Répertoire agrégation combine des entités
Domaine services modèle principal opérations
Référentiels enregistrement et Dispense répertoire Agrégation
Le Thing avec des bases de données
Mise en route de DDD

Création du domaine géré par (DDD) est un ensemble de principes et modèles qui permettent aux développeurs concevoir des systèmes de l'objet élégante.Elle est appliquée correctement il peut entraîner abstractions logiciels appelées modèles de domaine.Ces modèles encapsulent la logique métier complexes, fermeture de l'espace entre réalité de l'entreprise et le code.

Dans cet article, j'aborderai les concepts de base et motifs de conception germane à DDD.Considérez cet article comme une introduction chers à Création et évolution domaine enrichi modèles.Pour fournir contexte à la discussion, j'utilise un domaine métier complexes avec laquelle je suis familier : gestion des stratégies d'assurance.

Si les idées présenté ici appel, je recommande vivement deepen votre boîte à outils, lisez le livre Domain-Driven Design: Tackling Complexity in the Heart of Software, par Eric Epèrs.Il est plus que simplement l'introduction d'origine DDD, un trove trésor d'informations par un des concepteurs de logiciels plus chevronnés l'industrie.Les motifs et les principes de base de DDD j'aborderai dans cet article sont dérivés les concepts qui sont détaillées dans ce manuel.

Contextes Couper par besoin architecturale

Contextes Bounded needn't être organisés uniquement par la zone fonctionnelle d'une application.Elles sont très utiles en divisant un système pour obtenir des exemples architecturales souhaités.L'exemple classique de cette approche est une application qui possède un encombrement transactionnelle robuste et un ensemble de rapports.

Il est souvent souhaitable dans ces circonstances (qui peuvent se produire assez souvent) pour rompre la génération d'états base de données de la base de données transactionnelle.Vous souhaitez que la liberté de poursuivre le degré de droit de la normalisation pour développer des rapports fiables, et vous souhaitez utiliser un mappeur objet-relationnel afin que vous pouvez conserver coder logique métier transactionnelles dans le paradigme orienté objet.Vous pouvez utiliser une technologie tels que Microsoft Message Queue (MSMQ) pour publier des mises à jour des données provenant du modèle et les intégrer les data warehouses optimisés fins d'analyse et de génération d'états.

Ce peut-être être comme une décharge à certaines, mais il est possible pour les administrateurs de base de données et les développeurs obtenir le long.Contextes Bounded donnera un aperçu de ce terrain promised.Si vous êtes intéressé par l'architecture contextes limitée, je vous recommande vivement conserver onglets enBlog de Greg Young. Il a très expérimenté avec et expliquer à propos de cette approche et génère un certain volume de contenu sur le sujet.

Le modèle Platonic

Étant donné que nous commencez simplement désactiver ici, il est judicieux pratique pour définir ce que je VEUX dire par modèle.La réponse à cette question nous mène sur une entrée courte et metaphysical.Qui mieux que Platon pour nous aider ?

Platon, qui étudiant plus célèbre de Socrate, proposé que place les concepts, personnes, et nous intuit et ont avec notre senses est simplement des ombres de la vérité.Il répondant noms cette idée d'un élément de cette propriété a la valeur true un formulaire.

Pour expliquer les formulaires, Platon utilisé ce qu'est deviennent appelle le allegory de la cave.Dans ce allegory, il existe un personnes qui sont liés dans un cave profond, sombre.Ces cave personnes sont liés de telle sorte qu'ils peuvent voir seulement jamais un mur vide de la cave reçoit le voyant de l'ouverture.Lorsqu'un animal parcourt à l'ouverture, une ombre est projetée sur le mur intérieur que les dwellers cave voir.Les dwellers cave, ces ombres sont la chose réelle.Lorsqu'une lion parcourt en, ils pointez sur l'ombre de la lion et exclaim « exécuter pour couverture! » Mais il est vraiment uniquement une ombre du formulaire réel, le lion lui-même.

Vous pouvez associer théorie de Platon de formulaires à DDD.Grande partie de ses conseils permet de nous approchez au modèle idéal dans le temps.Le chemin vers le formulaire que vous souhaitez décrire avec votre code est répartie sur dans l'enfant d'experts du domaine, les désirs de participants et les besoins de secteurs d'activité dans lequel nous nous efforçons.Il s'agit, dans un sens très réel, les ombres à dwellers cave imaginaires de Platon.

En outre, vous sont souvent limitées en langages de programmation et considérations de temps et le budget dans essayez d'atteindre que formulaire.Il n'est grande partie une échelle à dire que ces limitations sont l'équivalent des dwellers cave seulement jamais la possibilité d'afficher le panneau interne d'ombres pas.

Modèles de bonnes présentent un nombre d'attributs indépendamment de leur implémentation.Le fait de la question est la différence entre le modèle de tête de tout le monde et le modèle que vous vous engager à code est la première chose qu'un Modeleur domaine aspiring doit comprendre.

Le logiciel que vous créez n'est pas le modèle de cette propriété a la valeur true.Il est uniquement une manifestation, une ombre, si vous serez, de l'application formulaire que vous définissez sur Atteindre.Même s'il est une imitation de la solution parfaite, vous pouvez chercher à amener ce code de plus près à la fiche de cet argument a la valeur true dans le temps.

Dans DDD, cette notion est appelée conception de base de modèles.Votre présentation du modèle d'est évoluée dans votre code.Concepteurs piloté par domaine serait plutôt pas préoccuper tonnes de documentation ou épais outils de création de diagrammes.Qu'ils recherchent, au lieu de cela, à imbue leur sens de la présentation domaine directement dans leur code.

L'idée du code capture le modèle est principal à DDD.Vous en conservant votre logiciel axé sur le problème en cours et contraint pour résoudre ce problème, vous retrouvez avec les logiciels réceptifs aux nouvelles idées et instants d'enlightenment.J'apprécie que Eric Epèrs les appels : crunching des connaissances dans des modèles.Lorsque vous apprendre quelque chose d'important sur le domaine, vous saurez droite où aller.

Communiquer avec le parler

Examinons des techniques que ddd fournit pour atteindre cet objectif.Une grande partie de votre travail en tant que développeur fonctionne non codeurs de comprendre ce que vous vous comptiez à livrer.Si vous travaillez dans une organisation avec n'importe quel type de processus, vous avez probablement des exigences exprimée sous la forme un article de l'utilisateur, des tâches, ou utiliser cas.Que type de besoins ou spécification que vous recevez, est-il généralement complète ?

En général exigences sont un peu murky ou exprimé à un niveau élevé de compréhension.Au cours de création et en implémentant une solution, il est intéressant lorsque les développeurs ont accès aux personnes avancer des compétences du domaine souhaité.Cela est exactement le point d'utilisateur articles, qui sont généralement exprimées according to un modèle comme suit : comme un [rôle], je veux [fonction] donc que [Bénéfice].

Prenons un exemple à partir du domaine de gestion de police d'assurance : comme un underwriter je souhaitez approbation contrôler une stratégie pour que je puissent écrire exposures sûrs et rejeter celles à risque.

Y a-t-il toute personne qui comprend ce que cela signifie ?Je sais que je n'a pas lorsque J'AI vu écrit et définir la priorité.Comment pouvez vous éventuellement comprendre tout ce qui devra passer en livraison le logiciel de prise en charge à partir de cette description abstraites ?

Stories, utilisateur, correctement terminé, est une invitation à avoir une conversation avec leur auteur, l'utilisateur.Cela signifie que lorsque vous accédez à travailler sur la fonctionnalité de stratégie approbation/refuser, vous devez idéalement accéder à un underwriter.Underwriters, pour les débutants, sont des experts domaine (celles moins bonnes sont) qui déterminer si une certaine catégorie d'exposition est sûr pour un opérateur couvrir.

Lorsque vous commencez à aborder la fonction avec votre underwriter (ou whomever votre expert domaine projet peut être), salaire fermer particulièrement attention à la terminologie le underwriter utilise.Ces experts du domaine utilisent terminologie standard de société ou de secteur d'activité.Dans la DDD, cette terminologie est appelée le langage omniprésents.En tant que développeurs, que vous souhaitez comprendre ce vocabulaire et non seulement le utiliser lorsque vous parlez avec des experts du domaine mais également afficher la même terminologie apparaissent dans votre code.Si le termes « code de classe », ensembles de taux ou « exposition » est fréquemment utilisée dans conversation, je s'attendre à rechercher les noms de classe correspondants dans le code.

Ceci est un motif assez fondamental à DDD.Au premier blush, la langue omniprésents semble une chose évidente et il est probable Qu'est un bon que nombre de vous est déjà exercices ce intuitivement.Cependant, il est essentiel que les développeurs utiliser la langue métier dans le code consciously et comme une règle de méthodes.Cela réduit la déconnexion de vocabulaire métier et technologiques un terme du jargon informatique.La façon de devient subordonné pour le que, et vous restez plus proche de la raison de votre travail : fourniture de valeur ajoutée.

Contexte

Les développeurs sont dans un sens, organisateurs.Vous sling code avec un peu de chance avec intention) dans les abstractions résoudre les problèmes.Outils comme modèles de conception, architectures superposés et principes orientée objet donner une structure pour appliquer des commandes à evermore systèmes complexes.

DDD étend votre boîte à outils organisation et adapté des langages de motifs de secteur d'activité réservé.Ce que j'aime plus sur les motifs d'organisationnels qui dispose DDD est qu'il y a solutions pour chaque niveau de détail dans un système.Contextes Bounded vous guident vers pensée de logiciels comme un ensemble de modèles.Modules vous aident à organiser un seul modèle plus grand en segments plus petits.J'aborderai plus tard, racines agrégation comme une technique pour l'organisation petites collaborations entre quelques classes très associées.

Dans Entreprise la plupart des systèmes il sont fine cours-domaines de responsabilité.DDD appelle ce niveau supérieur d'organisation un contexte limitée.

Indemnités pour accident assurances doivent préoccuper des éléments tels que :

• Quoting et de vente
• Flux de travail stratégie général (renouvellements, arrêts)
• L'audit de l'estimation de paie
• Trimestre self-estimates
• Définition et la gestion des taux
• Émission de commissions aux agences et les courtiers
• Clients de facturation
• Comptabilité générale
• Détermination des exposures acceptables (souscription)

WOW.C'est beaucoup de choses !Vous pourriez intégrer tout cela un système monolithique unique, mais vous donc vous guide vers le bas un chemin d'accès foggy, amorphous.Personnes parlez sur deux choses totalement différentes lorsqu'elles discuter sur une stratégie dans le contexte d'un flux de travail général et une stratégie dans le contexte de l'audit de paie.Si vous utilisez la même classe de stratégie, vous êtes fattening le profil de cette classe de l'un moyen long essayé-et-true recommandées comme le principe de gestion unique (SRP).

Les systèmes qui n'isoler et isolation contextes délimitée souvent bon dans un style Architecture (amusingly) appelé le grand ballon de Mud.En 1999, Brian ' s Foot et Joseph Yoder définis le style d'architecture (ou style anti-architectural, comme le cas peut être) dans leur document classique du même nom «Grand ballon de Mud").

DDD déplace vous identifier contextes et contrainte les efforts de modélisation de contextes particuliers.Vous pouvez utiliser un diagramme simple, appelé une carte de contexte, pour Explorer les limites de notre système.J'ai énumérés les contextes impliqués dans un système de gestion de police d'assurance entièrement proposé et figure 1 prend cette de texte de description à une carte de contexte graphique (partiel).

Figure 1 de carte contexte à contexte Bounded

Avez-vous remarqué certaines relations clées entre les différents contextes délimitée ?Cela est intelligence utile car vous pouvez démarrer informé métier et les décisions architecturales comme Empaquetage et déploiement ; choix de technologie utilisé pour marshaler des messages entre modèles et peut-être plus important, où vous choisir de définir des jalons et déployer des efforts, heure et talent.

Une dernière pensée mais très importante sur les contextes délimitée : chaque contexte possède son propre langage omniprésents.Il est important différencier la notion d'une stratégie dans le sous-système d'audit et la stratégie de flux de travail principal parce qu'elles sont choses différentes.Alors qu'ils peuvent avoir la même identité, les objets de valeur et des entités enfants (plus sur ces un peu) sont souvent radicalement différentes.Étant donné vous êtes de modélisation dans contexte, vous voulez également que la langue à fournir la précision dans ce contexte pour avoir pouvez productive communication avec des experts du domaine et de vos équipes.

Certaines zones dans groupe de modèles plus étroitement ensemble que d'autres.Modules constituent un moyen d'organiser ces groupes dans un contexte particulier, servant de mini-limites souhaité pour arrêter penser associations avec d'autres modules.Ils sont également une autre organisation technique qui vous guide éloignez « Small que de Mud ». Techniquement, modules sont faciles à créer ; dans le Microsoft .NET Framework ils sont simplement les espaces de noms.Mais l'image d'identifier les modules implique de passer un peu de temps avec votre code.Vous pouvez éventuellement voir choses se posent comme un mini-model dans un modèle, moment auquel vous pouvez envisager diviser les choses en espaces de noms.

Teasing les modèles en modules cohésifs effet intéressante dans l'IDE.À savoir, car vous devez utiliser plusieurs à l'aide instructions pour inclure des modules explicitement, vous obtenir une expérience IntelliSense beaucoup améliorée.Elles aussi vous permettent d'examiner les associations entre les portions conceptuelles supérieures de votre système avec un outil d'analyse statique tel que NDepend.

Introduction d'un changement d'organisation à votre modèle doit vous inviter à participer à certaines pragmatic, le coût / avantage penser.Lorsque vous utilisez modules (ou espaces de noms) pour diviser les votre modèle, vous voulez vraiment question si vous avez affaire à un contexte séparé.Le coût de cleaving hors d'un autre contexte est généralement beaucoup plu : maintenant avoir deux modèles, probablement dans deux assemblys, vous devez vous connecter avec les services d'application, contrôleurs et ainsi de suite.

Anti-Corruption Layers

Une couche Anti-Corruption (ACL) est un autre motif DDD qui vous permet de créer gardien ce travail pour empêcher la fuite dans votre modèle de concepts non domaine encourage.Elles conservent le modèle en mode minimal.

À leur cœur référentiels sont en fait un type de liste de contrôle d'accès.Ils conservent SQL ou constructions de mapping objet-relationnel (ORM) en dehors de votre modèle.

Listes de contrôle d'accès sont une technique très pour introduire les Michael Feathers appelle, dans son livre Working Effectively With Legacy Code, un seam.Un seam est une zone où vous pouvez commencer à cleave hors du code hérité et commencer à présenter seams changes.Finding, avec l'isolation de votre domaine principal, peuvent être extrêmement utile lorsque vous utilisez DDD techniques pour refactor et renforcer les parties valeur plus élevées de votre code.

Connaître votre proposition de valeur

La plupart des magasins de développement ont quelques de chevronné professionnels et développeurs supérieur qui sont capables d'isoler et qui décrit un problème et création d'une solution orientée objet élégante, plus facile à gérer.Pour obtenir le bang plus important pour euro votre client, vous souhaitez que comprendre le domaine principal de votre application.Le domaine principal est le contexte limitée qui fait descendre la valeur de la plupart à appliquer DDD.

Dans n'importe quel système d'entreprise donné, il existe certaines zones sont plus importants que d'autres personnes.Les zones plus importantes ont tendance à se répartissent en alignement avec les compétences de base du client.Il est rare qu'une entreprise s'exécute logiciel personnalisé du grand livre.Mais si cette entreprise est en assurance (aller dans mon exemple précédent) et leur offre des modifications de l'argent est Gestion des risques pools passif est réparti entre tous les membres, puis dont ils disposaient mieux être darned bon au rejet de risques incorrectes et identifier des tendances.Ou vous avez peut-être un client qui est un processeur de déclarations médical, et leur stratégie doit flank leurs concurrents de tarification en automatisant paiements amplifier les efforts de leurs employés payor nomenclature.

Quel que soit le secteur d'activité, votre employeur ou votre client a une bordure sur le marché, et ce bord est généralement où vous trouver les logiciels personnalisés.Ce logiciel personnalisé est où vous êtes susceptible rechercher et de modéliser le domaine principal.

Nous pouvez mesurer notre investissement dans la valeur sur une autre dimension, à savoir ce qui où nous investir notre MAJUSCULE intellectuelle dans atteindre excellence technique.Les développeurs souvent trop senior sont le type de personnes obtenir obsessed avec les nouvelles technologies.Un volume certain de cette est être attendu, l'industrie innovates à un rythme relentless et fournisseurs sont compelled pour lancer fréquemment nouvelles offres de technologie de satisfaire les demandes des clients vous souhaitez rester compétitif.Le défi, comme je le voir, est senior aux développeurs de maîtriser les principes fondamentaux et les motifs qui contribuent valeur pour le coeur d'un système.Il est tentant d'obtenir encapsulée dans une nouvelle infrastructure ou de la plate-forme, mais nous devez mémoriser le produisent fournisseurs raison ces éléments est donc nous pouvez uniquement approuver qu'elles fonctionnent.

Un système de responsabilités unique

J'ai mentionné que DDD fournit un langage motif pour la structuration du domaine enrichi modèles.En implémentant ces modèles, vous obtenir gratuitement un certain niveau du respect du SRP, et c'est certainement utile.

Le SRP encourage obtenir à l'objectif principal d'une interface ou une classe.Il vous guide vers cohésion élevée, une très bonne chose, telle qu'elle facilite code découvrir, réutiliser et tenez à jour.

DDD identifie certains types de classe responsabilités dans une collection principaux de modèles.J'aborderai quelques celles plus primaires maintenant, mais il est important de mentionner qu'il existe de nombreux modèles décrits par Eric Epèrs dans le catalogue d'origine allant de niveau classe à architecture.À des fins de présentation, je vous rester au niveau classe couvrant entités, objets de la valeur, agrégation racines, services de domaine et référentiels.Étant donné qu'il s'agit d'une présentation, j'aborderai uniquement la responsabilité de chaque modèle avec des exemples de code un à deux ou conseils.

Entités ont des identités et une durée de vie

Une entité est une « chose » dans votre système.Il est souvent utile de penser à ces en termes de noms : personnes, lieux et, enfin, les choses.

Entités ont une identité et un cycle de vie.Par exemple, si je souhaitez accéder à un client particulier dans mon système, J'AI pouvez demander pour son par un nombre.Lorsque J'AI terminé un ordre commercial, il fait ensuite inactive dans mon système et pouvez accéder à un stockage à long terme (système rapport historique).

Imaginez entités comme unités de comportement plutôt que comme unité de données.Essayez de mettre votre logique dans les entités qui possèdent les.La plupart des heures est une entité qui doit recevoir une opération que vous tentez d'ajouter à votre modèle ou une nouvelle entité est begging d'être créé ou extraites.Dans le code anemic plus, vous trouver beaucoup de classes de service ou le responsable qui valider les entités de l'extérieur.En règle générale, je préfère bien faire à partir de l'entité, vous recevez tous les avantages associés le principe fondamental de l'encapsulation, et que vous apportez vos entités comportementale.

Certains développeurs sont peine en laissant les dépendances dans les entités.Évidemment, vous devez créer des associations entre les différentes entités de votre système.Par exemple, vous devrez peut-être obtenir une entité de produit à partir de l'entité de stratégie afin que vous pouvez déterminer sensé par défaut de la stratégie.Lorsque vous avez besoin certains hors service pour exécuter comportement intrinsèque à une entité où personnes semblent écrouler est.

Pour une, ne je pas perturbé par la nécessité d'impliquent des classes d'autres, non entité, et je serait essayez éviter capture le comportement central en dehors de mon entité.Souvenez-vous toujours qu'entités sont intrinsèquement comportementales unités.Ce comportement est souvent être implémenté comme un type de machine d'état, lorsque vous appelez une commande dans une entité, il est responsable de modifier son état interne, mais parfois, il est nécessaire pour pouvoir obtenir des données supplémentaires ou imposer des effets secondaires sur le monde extérieur.Mon technique préférée pour accomplir cela consiste à fournir la dépendance à la méthode de commande :

public class Policy {
  public void Renew(IAuditNotifier notifier) {
    // do a bunch of internal state-related things,
    // some validation, etc.
    ...
    // now notify the audit system that there's
    // a new policy period that needs auditing
    notifier.ScheduleAuditFor(this);
  }
}

L'avantage de cette approche est que vous n'avez pas besoin une inversion du conteneur de contrôle (IOC) pour créer une entité pour vous. Une autre approche parfaitement acceptable, à mon avis, est d'utiliser un localisateur de service pour résoudre le IAuditNotifier dans la méthode. Cette technique présente l'avantage de conserver l'interface propre, mais je trouve que la première stratégie m'indique que beaucoup plus mon dépendances à un niveau plus élevé.

Objets de la valeur de décrire les éléments

Les objets de valeur sont descripteurs ou propriétés importantes dans le domaine que sont de modélisation. Contrairement aux entités, ils ne possèdent pas une identité ; ils décrivent simplement les éléments qui ont d'identités. Les vous modifier une entité appelée « trente - cinq dollars » ou sont incrémenter le solde d'un compte ?

Partie de la beauté d'objets de la valeur est qu'ils décrivent les propriétés d'entités de manière beaucoup plus élégante et révéler l'intention. Argent, un objet de valeur courants, ressemble beaucoup mieux comme paramètre de fonction sous un transfert de fonds API qu'un nombre décimal. Lorsque vous les repérer dans une méthode d'interface ou d'une entité, vous savez que vous avez affaire à immédiatement.

Les objets de valeur sont immuables. Ils sont n'est pas capable d'effectuer de modification qu'elles sont créées. Pourquoi est-il important qu'ils soient immuable ? Avec les objets de valeur, vous êtes recherche côte effet à libérer fonctions, mais un autre concept est emprunté par DDD. Lorsque vous ajoutez 20 EUR à 20, vous modifiez 20 ? Non, vous créez un nouveau descripteur de money de 40 EUR. En C# vous pouvez utiliser le mot clé en lecture seule sur les champs publics pour appliquer immuabilité et fonctions côte effet à libérer, comme illustré figure 2 .

Figure 2 Utilisation en lecture seule à appliquer immuabilité

public class Money {
  public readonly Currency Currency;
  public readonly decimal Amount;

  public Money(decimal amount, Currency currency) {
    Amount = amount;
    Currency = currency;
  }

  public Money AddFunds(Money fundsToAdd) {
    // because the money we're adding might
    // be in a different currency, we'll service 
    // locate a money exchange Domain Service.
    var exchange = ServiceLocator.Find<IMoneyExchange>();
    var normalizedMoney = exchange.CurrentValueFor(fundsToAdd,         this.Currency);
    var newAmount = this.Amount + normalizedMoney.Amount;
    return new Money(newAmount, this.Currency);
  }
}

public enum Currency {
  USD,
  GBP,
  EUR,
  JPY
}

Répertoire agrégation combine des entités

Racine d'un regroupement est un type spécial d'entité qui font référence aux consommateurs à directement. Identification racines regroupement permet d'éviter over-coupling les objets qui composent votre modèle en imposant quelques règles simples. Vous devez noter que racines agrégation protéger leurs sub-entities zealously.

N'oubliez pas la règle plus importante est qu'agrégation racines sont le seul type d'entité à laquelle votre logiciel peut conservent une référence. Cela permet d'éviter le grand ballon de Mud car vous désormais une contrainte qui vous empêche de création d'un système étroitement couplée où tout a une association pour tout le reste.

Supposons que j'ai une entité appelée stratégie. Stratégies obtenir renouvelés sur un terme annuel, donc il est probablement une entité appelée période. Comme une période ne peut pas exister sans une stratégie et de gérer périodes via la stratégie, stratégie est considéré comme racine d'un regroupement et période est un enfant de la même.

J'aime mes racines Agrégation de simplement déterminer qu'il pour moi. Examinons ce code consommateur accéder à une racine agrégation stratégie :

Policy.CurrentPeriod().Renew() 

J'essaie de renouveler une police d'assurance, rappeler le diagramme de classes du domaine principal de la gestion de police d'assurance. Notez comment je suis dotting mon permet le comportement que je souhaite appeler ?

Il existe plusieurs des problèmes liés à cette approche. Tout d'abord, je suis clairement enfreint la loi Demeter. Une méthode M d'un objet O doit appeler uniquement les méthodes de types d'objets suivants : lui-même, ses paramètres, les objets qu'il crée ou instancie ou ses objets composants direct.

N'est pas en profondeur dotting de pratique ? IntelliSense est une des fonctionnalités de Visual Studio et autres IDE modernes coolest et plus utiles, mais lorsque vous démarrez dotting votre permet la fonction que vous voulez appeler, vous introduisons inutiles associant dans le système. Dans l'exemple précédent, je suis désormais en fonction de la classe de stratégie et de la classe période.

Pour plus lire, Appleton Brad a un excellent article disponible sur son site qui décrit les implications approfondies, theories, Outillages et caveats autour de la La loi de Demeter.

Le cliche "mort par coupe mille" est une bonne description de la maintenance potentiel cauchemar en termes d'un système très couplée. Lorsque vous créez des références inutiles tout sur l'emplacement, vous créez également un modèle rigide où les modifications en un seul endroit entraîner une cascade des modifications tout sur code client. Vous pourriez atteindre le même objectif avec, concerné loin que je suis, un peu plus expressif de code :

Policy.Renew()

Voir comment le regroupement simplement détermine qu'il ? En interne il trouverez de la période en cours ; il existe déjà ou non une période de renouvellement et ce autre que vous avez besoin pour faire.

Je trouve qu'en lorsque je suis test mes racines agrégation utilisant une technique comme Behavior-Driven développement (BDD), mes tests tendance vers le paradigme plus boîte noire et state-test. Agrégation racines et des entités souvent terminer en tant qu'état ordinateurs et le comportement correspond en conséquence. J'AI finissent avec état de validation, addition et soustraction. Il est tout à fait un peu de comportement passe dans l'exemple de renouvellement dans la figure 3 et il est très claire comment vous pouvez exprimer cela dans un style BDD de test.

La figure 3 test agrégation racines

public class 
  When_renewing_an_active_policy_that_needs_renewal {

  Policy ThePolicy;
  DateTime OriginalEndingOn;

  [SetUp]
  public void Context() {
    ThePolicy = new Policy(new DateTime(1/1/2009));
    var somePayroll = new CompanyPayroll();
    ThePolicy.Covers(somePayroll);
    ThePolicy.Write();
    OriginalEndingOn = ThePolicy.EndingOn;
  }

  [Test]
  public void Should_create_a_new_period() { 
    ThePolicy.EndingOn.ShouldEqual(OriginalEndingOn.AddYears(1));
  }
}

Domaine services modèle principal opérations

Parfois, vous avez opérations ou des processus qui n'ont pas d'une identité ou le cycle de vie de votre domaine. Services de domaine permettent un outil pour ces concepts de modélisation. Ils êtes généralement sans état et hautement cohésifs, souvent fournissant une méthode publique unique et parfois, une surcharge pour agir sur des ensembles.

J'aime d'utiliser des services pour plusieurs raisons. Si un certain nombre de dépendances sont impliquées dans un comportement et Impossible de trouver un emplacement naturel d'une entité pour placer ce comportement, je vais utiliser un service. Lorsque ma langue omniprésents traite d'un processus ou opération comme un concept de premier ordre, je vous question si un service est logique de point central d'orchestration pour le modèle.

Vous pouvez utiliser un service de domaine dans le cas de renouvellement. Ceci est un autre style. Plutôt que la méthode injecter une IAuditNotifier directement dans la méthode de renouvellement méthode l'entité de stratégie de, vous pouvez choisir d'extraire un service de domaine pour gérer les dépendances pour nous ; il est plus naturelle pour nous résoudre un service de domaine à partir d'un conteneur IOC à une entité. Cette stratégie effectue beaucoup plus logique dans me lorsqu'il existe plusieurs dépendances, mais je présenterai L'alternative quand même.

Voici un exemple court d'un service de domaine :

public class PolicyRenewalProcesor {
  private readonly IAuditNotifier _notifier;

  public PolicyRenewalProcessor(IAuditNotifier notifier) {
    _notifier = notifier;
  }
  public void Renew(Policy policy) {
    policy.Renew();
    _notifier.ScheduleAuditFor(policy);
  }
}

Le service mot est un terme hautement surchargé dans le monde de développeur. Parfois, je pense que du service en architecture orientée service (SOA). Autres moments que je pense services en tant que peu de classes qui n'est pas représenter une personne en particulier, emplacement ou chose dans mon application, mais qui ont tendance à représenter les processus. Services de domaine se trouvent généralement dans cette catégorie de ce dernier. Ils ont tendance à être nommé d'après les verbes ou activités métier experts du domaine introduisent dans le langage omniprésents.

Services d'application, sont d'autre part, un moyen idéal pour introduire une architecture en couches. Ils peuvent être utilisés pour mapper des données dans le modèle de domaine à une forme requise par une application cliente. Par exemple, vous devez peut-être afficher des données tabulaires dans un DataGrid, mais vous souhaitez conserver un graphique d'objet précis et irrégulier dans votre modèle.

Services d'application sont également très utiles pour l'intégration de plusieurs modèles, par exemple, conversion entre le workflow de stratégie d'audit et de base de stratégie. De même, j'utilise les pour importer des dépendances d'infrastructure dans la gamme. Imaginez un scénario courant dans lequel vous souhaitez exposer votre modèle de domaine avec Windows Communication Foundation (WCF). Je souhaitez utiliser un service application décoré avec les attributs WCF pour rendre ce arriver plutôt que de laisser fuite de WCF dans mon modèle de domaine pur.

Services d'application ont tendance à être très large et peu profond, embodying fonctionnalité cohésifs. Pensez l'interface et une implémentation partielle que vous voir dans le code dans la figure 4 un bon exemple d'un service d'application.

Service d'application simple 4 A figure

public IPolicyService {
  void Renew(PolicyRenewalDTO renewal);
  void Terminate(PolicyTerminationDTO termination);
  void Write(QuoteDTO quote);
}

public PolicyService : Service {
  private readonly ILogger _logger;
  public PolicyService(ILogger logger, IPolicyRepository policies) {
    _logger = logger;
    _policies = policies;
  }

  public void Renew(PolicyRenewalDTO renewal) {
    var policy = _policies.Find(renewal.PolicyID);
    policy.Renew();
    var logMessage = string.Format(
      "Policy {0} was successfully renewed by {1}.", 
      Policy.Number, renewal.RequestedBy);
    _logger.Log(logMessage);
  }
}

Référentiels enregistrement et Dispense répertoire Agrégation

Où pouvez-vous accéder pour récupérer des entités ? Comment vous stocker ? Ces questions sont réponse par le modèle d'espace de stockage. Référentiels représentent une collection en mémoire, et la pratique conventionnelle est que vous vous retrouvez avec un référentiel par racine globale.

Référentiels sont un bon candidat pour une classe super ou ce à quoi Martin Fowler fait référence comme le motif de couche supertype. L'utilisation de génériques dériver une interface de base espace de stockage de l'exemple précédent est une question simple :

public interface IRepository<T>
  where T : IEntity
{
  Find<T>(int id);
  Find<T>(Query<T> query);
  Save(T entity);
  Delete(T entity);
}

Référentiels empêcher les concepts de base de données ou la persistance, tels qu'instructions SQL ou procédures stockées, de combinaison avec le modèle et vous distraire à partir de la mission en cours : capture le domaine.Cette séparation de code de modèle à partir d'infrastructure est un attribut bon.Consultez l'encadré « Layers Anti-Corruption » pour une étude plus détaillée.

À ce stade, vous avez probablement remarqué que je ne suis pas parler racines comment regroupement, les entités subordonnées, et les objets de valeur associés en fait obtenir conservées sur le disque.Ceci est intentionnel.Enregistrer les données requises pour effectuer comportement de votre modèle est une préoccupation orthogonale au modèle lui-même.Persistance est infrastructure.

Une étude de ces technologies ne beaucoup entre pas dans le cadre d'une introduction aux DDD.Suffice il dire qu'il existe un certain nombre d'options appropriés et à pour stocker les données votre modèle de mappage objet-relationnel (ORM) infrastructures bases de données orientées de documents à mappeurs de données "roll-your-propriétaire" pour les scénarios simples.

DDD ressources

Le site officiel DDD

Dan Nord sur comment faire pour structure utilisateur articles

Le grand ballon de Mud style architecturale

Blog de Greg Young sur CodeBetter

Robert c.Papier de Martin en principe de gestion unique

Brad Appleton sur la loi de Demeter

Martin Fowler décrit le modèle de supertype Layer

Robert c.Martin dans le S.O.L.I.D.Principes

Le Thing avec des bases de données

Par ce stade, je suis sûr vous avez pensé, « il convient tout bien et, Dave.Mais où j'enregistrer mon entités? » Oui, vous avez à gérer ce détail important, mais comment ou où vous conserver vos modèles est essentiellement tangential à une vue d'ensemble des DDD.

De développeurs ou administrateurs de base de données permettent l'assertion que la base de données est le modèle.Dans un lot de cas, c'est partiellement vrai.Bases de données, lorsque très normalisé et visualized avec un outil de création de diagrammes, peuvent transmettre un lot sur les informations et les relations dans votre domaine.

Données de modélisation comme une technique principale laisse quelque chose pour être nécessaire, cependant.Lorsque vous souhaitez comprendre les problèmes inhérents dans le même domaine, techniques uniquement des données telles que les diagrammes d'entité-relation (ERDs) ou des modèles d'entité-relation et décomposer les diagrammes de classes.Vous devez voir composants de l'application dans motion et comment les types de collaborer pour réaliser travail.

Lorsque je suis modélisation, J'AI souvent Atteindre pour diagrammes de séquence sur un tableau blanc comme outil de communication.Cette approche capture grande partie de l'essence de communiquer une conception comportementale ou problème sans la cérémonie de UML (Unified Modeling Language) ou architecture de base de modèles.J'aime éviter de cérémonie inutile, particulièrement lorsque je vais pour effacer les diagrammes que je placer dans le tableau blanc.Je ne vous inquiétez sur 100 % pas le respect des UML dans les mon diagrammes préférence zones simples, flèches et couloirs de natation j'esquisser rapidement.

Si vous n'utilisez déjà des diagrammes de séquence de votre équipe, je vous recommande vivement la technique de formation.J'ai observé leur effet puissant sur Obtenir les membres de l'équipe à considérer à problèmes autour du SRP, architecture en couches, conception comportement sur la modélisation des données et architecture penser en général.

Mise en route de DDD

Programmation orientée objet devenir proficient avec n'est aucun engagement trivial.Je pense compétence est dans le reach de plus professionnel aux développeurs, mais il prend respect, Carnet d'apprentissage et pratique, exercices et plus pratique.Il permet également si vous adopter une attitude de craftsmanship et formation continue.

Comment commencer ?Pour résumer : faire votre travail à domicile.Découvrez les éléments tels que leS.O.L.I.D.Principeset étude livre d'Eric Epèrs.Votre investissement fois plus de constitueront pour elle-même.InfoQ a publié une version inférieure du carnet de DDD qui introduit quelques concepts clés.Si vous êtes sur un budget financier ou temporelle ou simplement en mode d'investigation, je recommande démarrage il.Une fois que vous obtenez un footing uni, wander sur à laYahoo!DDD groupepour voir les problèmes de votre Bonhomme concepteurs struggling avec et Impliquez-vous dans la conversation.

DDD n'est pas un nouveau doctrine ou méthodologie.C'est une collection de stratégies time-tested.Lorsque vous obtenez prêt à la pratique, essayez adapter ces philosophies, les techniques et motifs qui sens plus dans votre situation.Certains éléments de DDD s'appliquent plus universellement que d'autres.Comprendre la raison d'existence votre domaine principal en uncovering et utilisant le langage omniprésents et identifier les contextes dans lesquels nous vous modélisation sont une manière plus importants que nailing ce référentiel parfaitement opaque et uniformisée.

Lorsque vous créez vos solutions, créer de valeur.Si concepteurs produisent des images et les développeurs sont un type de concepteur, notre support doit pouvoir se valeur métier.Valeur consciousness trumps considérations telles que le respect des dogma et choix de technologie de persistance, aussi importante que ces choix semble parfois.

Dave Laribee coaches l'équipe de développement du produit VersionOne.Il intervient fréquemment événements développeur locales et nationales et a décerné Microsoft Architecture MVP pour 2007 et 2008.Il écrit sur le réseau de blog CodeBetter authebeelog.com.