Il presente articolo è stato tradotto automaticamente.
Procedure consigliate
Un'introduzione A struttura basati sui domini
Nell'articolo viene descritto:
|
In questo articolo vengono utilizzate le seguenti tecnologie: Visual Studio |
Contenuto
Il modello Platonic
Contattare il Talk
Contesto
Conoscere la proposta di valore
Un sistema di un singolo ruolo
Entità dispongono di un'identità e una durata
Valore oggetti descrivere cosa
Directory principali aggregazione combina entità
Dominio servizi modello principale operazioni
Archivi Salva e lavorare informazioni delle directory principali
La cosa con database
Guida introduttiva a DDD
struttura di base del dominio (DDD) è un insieme di principi e modelli che consentono agli sviluppatori di creazione oggetto elegante sistemi.Applicato correttamente può causare astrazioni software denominate dominio modelli.Questi modelli incapsulano logica aziendale complesso, la distanza tra la situazione di business e codice di chiusura.
In questo articolo verrà descritta concetti di base e modelli di progettazione germane DDD.Considerare questo articolo come una gentle Introduzione alla progettazione ed evoluzione di modelli di dominio completo.Per fornire un contesto per la discussione, STO utilizzando un dominio aziendale complesso con cui sono noto: gestione polizza assicurativa.
Se le idee presentate qui impatto per l'utente, consigliabile ottimizzerà la casella degli strumenti mediante la lettura del manuale Domain-Driven Design: Tackling Complexity in the Heart of Software, da Brian Alboni.Più semplicemente l'introduzione originale DDD, è un vero Tesoro di informazioni da uno dei progettisti di software più esperti del settore.I motivi e dottrine della base di DDD verrà discusso in questo articolo sono derivati dai concetti sono descritte in dettaglio in questo manuale.
I contesti di taglio da necessario architetturali
I contesti delimitati non essere organizzati esclusivamente per l'area funzionale di un'applicazione.Sono estremamente utili per la divisione di un sistema per ottenere esempi Architettura desiderati.L'esempio classico di questo approccio è un'applicazione che dispone di un footprint transazionale affidabile e una raccolta di report.
È spesso preferibile in tali circostanze (che potrebbero verificarsi piuttosto spesso) per interrompere da database di report dal database transazionale.Si desidera libertà per valutare il livello a destra di normalizzazione per lo sviluppo affidabile report e si desidera utilizzare un mapping relazionale a oggetto in modo che può mantenere codifica regole di business transazionale nel paradigma orientato a oggetti.È possibile utilizzare una tecnologia, ad esempio Microsoft Message Queue (MSMQ) per pubblicare gli aggiornamenti di dati provenienti dal modello e incorporarli in data warehouse ottimizzati per scopi di reporting e analisi.
Questo potrebbe provenire come una sorpresa per alcuni, ma è possibile per gli amministratori di database e sviluppatori ottenere l'insieme.Contesti delimitati forniscono una panoramica di questo terreno promised.Se interessa in contesti di delimitata dell'architettura, consigliabile mantenere schede viaBlog di Greg Young. Egli è molto esperto con articulate su questo approccio e genera una notevole quantità di contenuto in base all'oggetto.
Il modello Platonic
Poiché è solo chi inizia disattivare, è opportuno pratico per definire il significato dal modello.Rispondere a questa domanda, ci porta in un breve e metaphysical spinto.Chi meglio Platone Guida Microsoft?
Platone, che più famoso studente di Socrate, proposti che inserisce i concetti, gli utenti, e le cose si intuit e percepire con nostro senses sono semplicemente ombreggiature della verità.Ha dubbed l'idea di un elemento true in un form.
Per illustrare form, Platone utilizzati cosa è diventano noto come allegory del cave.In questo allegory esiste un persone che sono associati all'interno di un cave completa, scuro.Questi cave persone sono concatenare in modo che possono vedere solo mai un muro vuoto di cave che riceve la luce dall'apertura.Quando un animale esamina per l'apertura, un'ombreggiatura verrà proiettata muro intero che visualizzano il dwellers cave.Dwellers cave, le ombreggiature sono la cosa reale.Quando un lion esamina da, sono posizionare l'ombreggiatura del lion ed exclaim, "Esegui per copertina". Ma è davvero solo un'ombreggiatura del form reale lion stesso.
È possibile correlato teoria del Platone di form ALL'DDD.Gran parte la Guida consente di noi ottenere più vicino al modello ideale nel tempo.Il percorso per il modulo che si desidera descrivere con il codice è dispersi sull'minds di esperti di dominio, i desideri dei cointeressati e i requisiti di settori in cui si lavora.Si tratta, in un senso molto reale, le ombreggiature per dwellers cave immaginario del Platone.
Inoltre, spesso sono vincolati dai linguaggi di programmazione e considerazioni del tempo e del preventivo tentativo di raggiungere che form.Non si tratta gran parte di un'estensione a dire che queste limitazioni sono l'equivalente di dwellers cave solo sempre la possibilità di vedere muro intero di ombreggiatura.
I modelli di buona è presente un numero di attributi indipendente dall'implementazione.Il fatto della questione è la mancata corrispondenza tra il modello di testina di tutti gli utenti e il modello in commit al codice è innanzitutto che necessario comprendere un modeler aspiring di dominio.
Il software che è creare non è il modello di true.È solo un manifestazione, se si sarà in grado di un'ombreggiatura, dell'applicazione form è impostare da ottenere.Anche se un imitation della soluzione perfetta, è possibile ricerca portare tale codice al form true nel tempo.
In DDD, è è che questo concetto denominato basato su modelli di progettazione.La conoscenza del modello è evoluta nel codice.Finestre di progettazione basato su dominio ma potrebbe non preoccuparsi con reams di documentazione o ad alta densità diagrammi di strumenti.Cercare, invece imbue il senso di comprensione del dominio direttamente in proprio codice.
L'idea di codice il modello di acquisizione è principali per DDD.Mantenendo il software occupano in manualmente il problema e vincolata per risolvere questo problema, terminare i con software receptive nuovi approfondimenti e minuti di enlightenment.MI piace cosa Alboni Eric chiama: crunching conoscenza in modelli.Quando informazioni su un elemento importante sul dominio, si saprà direttamente da eseguire.
Contattare il Talk
Esaminare alcune delle tecniche DDD fornisce per raggiungere questo obiettivo.Una grande parte del processo come sviluppatore utilizza non sviluppatori di comprendere cosa si intende per il recapito.Se si sta lavorando in un'organizzazione con qualsiasi tipo di processo, sarà probabilmente requisiti espresso come un brano di utente, attività o utilizzare la distinzione tra maiuscole e minuscole.Qualsiasi tipo di requisiti o specifica viene visualizzato, è in genere completa?
In genere requisiti sono piuttosto murky o espresso con un elevato livello di conoscenza.Nel corso di progettare e implementare una soluzione, è utile se gli sviluppatori hanno accesso agli utenti portare alcune conoscenze nel dominio specificato.Questo è esattamente il punto del brani di utente, in genere espresso according to un modello simile al seguente: come [ruolo], desidera [caratteristica] in modo che [vantaggio].
Diamo un esempio del dominio di gestione di polizza di assicurazione: come un underwriter desidera impostare approvazione preciso un criterio in modo che È possibile scrivere exposures sicuro e rifiutare quelle rischioso.
C'è chiunque riconosce che cosa ciò significa che?So che non quando HO visto scritto e priorità.Come è probabilmente comprendere tutto ciò che sarà necessario passare alla consegna il software di supporto da questa descrizione astratte?
Utente brani, eseguiti correttamente, sono un invito ad avviare una conversazione con i relativi autore, l'utente.Ciò significa quando si raggiunge di utilizzare la caratteristica di Approva o Nega, è necessario disporre in teoria accesso a un underwriter.Underwriters per inesperti, sono esperti di dominio (buona almeno quelli) che determinare se una determinata categoria di esposizione è sicura per un gestore telefonico coprire.
Quando si inizia la discussione la funzionalità con la underwriter (o whomever potrebbero essere esperti di dominio del progetto), retribuzione chiudere particolare attenzione la terminologia che utilizza il underwriter.Questi esperti dominio utilizzare terminologia standard società o del settore.In DDD, è è che questo vocabolario denominato del linguaggio di connettività.Come gli sviluppatori, che si desidera conoscere questo vocabolario e non solo utilizzato quando si parla con dominio esperti ma vedere anche la terminologia stessa riflesse nel codice.Se "classe codice delle condizioni" o set di frequenza "esposizione" vengono spesso utilizzati in conversazione, È necessario prevedono di trovare i nomi di classe corrispondente nel codice.
Questo è un motivo è fondamentale per DDD.Alla prima blush lingua connettività sembra una cosa ovvia e probabilità sono una buona che numerose si è già provare questa intuitivo.Tuttavia, è fondamentale che gli sviluppatori di utilizzare la lingua di business nel codice consciously e come una regola disciplined.In questo modo si riduce disconnessione tra vocabolario aziendale e gergo tecnologici.Come diventa subordinati al e non venga più vicina il motivo per il processo: valore aziendale di recapito.
Contesto
Gli sviluppatori sono in un certo senso, gli organizzatori della.Si sling codice con scopo) probabilmente in astrazioni risolvere i problemi.Strumenti come modelli di progettazione, architetture a più livelli e orientato a oggetti principi forniscono un framework applicazione ordine evermore sistemi complessa.
DDD estende la casella degli strumenti organizzativo e utilizza da modelli di settore noto.Ciò che mi piace più informazioni sui motivi organizzativi disposto DDD è che sono soluzioni per ogni livello di dettaglio in un sistema.I contesti delimitati Guida verso a pensare di software come una raccolta di modelli.I moduli consentono di organizzare un unico modello più grande in blocchi più piccoli.Successivamente, verranno descritta radici aggregazione come una tecnica per l'organizzazione piccole collaborazioni tra poche classi altamente correlate.
La maggior parte dei organizzazione sono i sistemi sono più capillare corso aree di responsabilità.DDD chiama questo alto livello di organizzazione un contesto delimitata.
È necessario le polizze assicurative compensazione ' Worker essere prioritaria elementi, ad esempio:
- Quoting e di vendita
- Criterio generale flusso di lavoro (i rinnovi, arresti)
- Controllo delle retribuzioni stima
- Self-estimates trimestrale
- Impostare e gestire tassi
- Emissione le commissioni di agenzie e brokers
- Fatturazione clienti
- Contabilità generale
- Determinazione exposures accettabile (underwriting)
WOW.È molto contenuti.È impossibile incorporare tutto ciò in un sistema unico, monolitica, ma tale così illustra un percorso foggy, a.Gli utenti sono parlare con circa due cose completamente diversi quando sono chat sui criteri di nel contesto di un flusso di lavoro generale rispetto a un criterio nel contesto di controllo delle retribuzioni.Se si utilizza la stessa classe di criteri, si sta fattening il profilo di tale classe e ottenere un modo lungo dal provato-e-true consigliate come singolo responsabilità modalità (SRP).
I sistemi che non riuscire a isolare e isolare i contesti delimitata spesso documento in un stile architetturale (amusingly denominato la grande pallina di Mud.Del 1999, Brian Foot Yoder Joseph definire e lo stile dell'architettura (o anti-architectural stile, come la distinzione tra maiuscole e minuscole potrebbe essere) i carta classico lo stesso nome "Grande pallina di Mud").
DDD spinge di identificare i contesti e strettamente l'impegno modellizzazione all'interno di contesti particolari.È possibile utilizzare un diagramma semplice, chiamato una mappa del contesto, per esaminare i limiti del nostro sistema.È stato enumerato i contesti che partecipano a un sistema di gestione polizza assicurativa completi, e figura 1 viene questo da una descrizione testuale a una mappa di contesto grafico (parziale).
Figura 1 da delimitato mappa di scelta rapida scelta rapida
È stato si verificano alcune relazioni di chiave tra i vari contesti delimitata?Questo è utile business intelligence poiché è possibile avviare aziendali consapevoli e decisioni architetturale ad esempio struttura assemblaggio e distribuzione; scelta della tecnologia utilizzati per effettuare il marshalling dei messaggi tra modelli e, forse la maggior parte importante, in cui si sceglie di impostare le attività cardine e distribuzione di sforzi, ora e talent.
Un ultimo ma molto importante pensiero su delimitata contesti: ogni contesto possiede un proprio linguaggio di connettività.È importante distinguere il concetto di un criterio nel sottosistema di controllo e il criterio nel flusso di lavoro di base perché sono operazioni diverse.Mentre potrebbe sono la stessa identità, gli oggetti di valore ed entità figlio ulteriori su in un bit sono spesso radicalmente diverse.Poiché sta modellizzazione all'interno di contesto, si desidera anche la lingua da fornire precisione all'interno di tale contesto e consentire quindi è possibile impostare la produttività comunicazioni con gli esperti di dominio e all'interno del team.
Alcune aree all'interno di gruppo di modelli più da vicino insieme rispetto ad altri.I moduli sono uno strumento di organizzare questi gruppi all'interno di un determinato contesto, che funge da mini limiti in cui si desidera arrestare e valutare le associazioni ad altri moduli.Sono anche un'altra tecnica dell'organizzazione che assiste l'utente opposta "Small gomma di Mud." Altrettanto, i moduli sono facili da creare; in Microsoft .NET Framework sono semplicemente spazi dei nomi.Ma l'immagine di identificazione di moduli prevede responsabile componenti dedicare qualche tempo con il codice.Infine è probabile che alcuni aspetti emersi come un mini-model all'interno di un modello, momento in cui si potrebbe considerare come divisione operazioni in spazi dei nomi.
Teasing modelli anello in moduli coerente ha un effetto interessante NELL'IDE.Più precisamente, poiché è necessario utilizzare più utilizzando le istruzioni per includere i moduli in modo esplicito, si ottiene una quantità pulitura esperienza IntelliSense.Sono inoltre consentono di esaminare le associazioni tra blocchi concettuali più grande del sistema tramite un strumento di analisi statica come NDepend.
Introduzione a una modifica organizzazione al modello. deve chiesto di operazioni di alcuni pragmatic, costo, vantaggi a pensare.Quando si utilizzano moduli o gli spazi dei nomi per suddividere il modello, davvero si desidera domanda se in Gestione un contesto separato.Il costo di cleaving da un altro contesto è in genere molto più alto: dopo avere due modelli, probabilmente in due assembly che è necessario connettersi a servizi dell'applicazione, controller e così via.
Livelli anti-Corruption
Un Anti-Corruption livello (ACL, Access Control List) costituito da un altro motivo di DDD incoraggia creare gatekeepers che è possibile utilizzare per impedire la perdita del modello di concetti non di dominio.Mantenere pulito il modello.
Il nucleo archivi sono effettivamente un tipo di elenco di controllo di accesso.Mantenere SQL o relazionali a oggetti mapping ORM (costrutti all'esterno del modello.
Elenchi di controllo di accesso sono una tecnica ottima per introdurre cosa Feathers Michael chiama, nel suo libro Working Effectively With Legacy Code, un seam.Un seam è un'area in cui è possibile iniziare a cleave Disattiva codice legacy e iniziare a introdurre seams changes.Finding, con l'isolamento del dominio principale, può essere estremamente utile quando si utilizzano tecniche DDD per eseguire il refactoring e applicazione le parti di valore più alte del codice.
Conoscere la proposta di valore
La maggior parte dei negozi di sviluppo necessario pochi di businesspeople esperti e gli sviluppatori superiore che sono in grado di isolamento che descrive un problema e creazione di una soluzione di orientato a oggetti elegante e gestibile.Per ottenere bang principale per buck il cliente, desiderato per essere certi che comprendere il dominio di base dell'applicazione.Il dominio principale è il contesto di delimitata porta il valore la maggior parte delle applicazione DDD.
In qualsiasi sistema dell'organizzazione specificato sono presenti alcune aree sono più importanti rispetto ad altri.Le aree più importanti tendono a sono suddivise in allineamento competencies la base del client.È raro che un'azienda eseguiranno software personalizzati Contabilità generale.Ma, se tale ufficio è di assicurazione (passare con il precedente esempio e le offerta apportare denaro è la gestione rischio pool in cui responsabilità viene distribuito tra tutti i membri, quindi avevano meglio essere darned buona rifiuto rischi non validi e identificare le tendenze.O forse si dispone di un client di un processore di attestazioni medici e propria strategia deve flank loro concorrenza sul prezzo automatizzando i pagamenti di amplificare l'impegno della propria forza lavoro payor distinta base.
Qualsiasi settore, il datore di lavoro o il client ha un bordo sul mercato e il bordo rappresenta in genere in cui è possibile trovare il software personalizzato.Tale software personalizzati è in cui è probabile trovare e il dominio principale del modello.
È possibile misurare l'investimento di valore in un'altra dimensione, ovvero in cui è investire il capitale intellettuale di raggiungere eccellenza tecnico.Gli sviluppatori troppo molte volte senior sono il tipo di utenti di ottenere obsessed grazie alle nuove tecnologie.Un determinate quantità di questo è a essere previsto, il settore innovates ritmo relentless e fornitori sono compelled per rilasciare spesso nuove offerte di tecnologia per soddisfare le richieste ai clienti e competitivi.La richiesta, come viene visualizzata, è senior agli sviluppatori di master i principi fondamentali e i motivi che contribuiscono valore per il fulcro del sistema.È tentato ottenere incapsulato alto in una piattaforma o nuovo framework, ma è necessario tenere presente la produzione di fornitori motivo queste operazioni è pertanto abbiamo semplicemente attendibili che lavorano.
Un sistema di un singolo ruolo
HO accennato che DDD fornisce un linguaggio di schema per i modelli di dominio completo di strutturazione.Implementando questi modelli è ottenere gratuitamente un determinato livello di conformità per il SRP, e certamente utile.
Il SRP incoraggia recupero allo scopo di principale di un'interfaccia o classe.Consente di verso coesione alta, un'ottima cosa, come semplifica codice individuare, riutilizzare e gestire.
DDD identifica alcuni tipi di responsabilità di classe in un insieme di base dei modelli.Verranno copriranno ora alcune di quelli più primarie, ma vale la pena accennando che esistono molti motivi descritto da Brian Alboni nel libro originale comprese tra a livello di classe e dell'architettura.Ai fini della introduttivo, verrà rimangono a livello di classe relativi entità, gli oggetti di valore, radici di aggregazione, Servizi di dominio e archivi.Poiché si tratta di un'introduzione, verrà si riferiscono solo la responsabilità di ogni motivo con uno di due esempi di codice o suggerimenti.
Entità dispongono di un'identità e una durata
Un'entità è un elemento nel sistema.Spesso è utile pensare a questi in termini di sostantivi: persone, luoghi e, ben, operazioni.
Entità dispongono sia un'identità e un ciclo di vita.Ad esempio, se desidera accedere a un determinato cliente in mio sistema, È possibile richiedere per l'utente da un numero.Quando completa un ordine di scambio, quindi è inattivo il sistema e può passare archiviazione a lungo termine (sistema report cronologico).
Può essere considerato entità come unità di comportamento anziché come unità di dati.Provare a inserire la logica in entità che possiedono le.La maggior parte delle volte non c'è un'entità che deve ricevere alcune operazioni che si sta tentando di aggiungere al modello o una nuova entità è begging da creare o estratti.Nel codice anemic più, è possibile trovare numerose servizio o manager classi che convalida entità dall'esterno.In generale molto preferisco a questo scopo da all'interno dell'entità, ottenere di tutti i vantaggi associati il principio fondamentale di incapsulamento e si desidera apportare le entità comportamento.
Alcuni sviluppatori sono necessario impostando dipendenze nelle entità.Ovviamente è necessario creare associazioni tra diverse entità nel sistema.Ad esempio, sarà necessario ottenere un'entità del prodotto dall'entità di criteri in modo è possibile determinare determinante le impostazioni predefinite del criterio.Gli utenti che sembrano rientrano verso il basso è quando occorre alcuni all'esterno di servizio per eseguire comportamento intrinseca a un'entità.
Per uno, non mi disturbato da dover riguardano le classi di altre, non entità e sarebbe tentare di evitare sollevare il comportamento centrale all'esterno del mio entità.Occorre tener sempre presente che le entità sono unità sé comportamento.Spesso questo comportamento verrà implementato come un tipo di computer di stato, quando si richiama un comando di un'entità, è responsabile di modifica relativo stato interno, ma in alcuni casi è necessario ottenere i dati aggiuntivi o imporre gli effetti collaterali al mondo esterno.La tecnica più usata per eseguire questo consiste di fornire la dipendenza al metodo di comando:
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);
}
}
Il vantaggio di questo approccio è che non è necessario un Inversione del contenitore del controllo (IOC) per creare un'entità. Un altro approccio perfettamente accettabile, secondo me, sarebbe per utilizzare un Locator del servizio per la risoluzione IAuditNotifier all'interno del metodo. Questa tecnica ha il vantaggio di mantenere l'interfaccia pulita, ma è possibile trovare che la strategia precedente avverte molto sulle mia dipendenze a un livello superiore.
Valore oggetti descrivere cosa
Gli oggetti di valore sono i descrittori o proprietà importanti nel dominio che sono di modellazione. A differenza di entità, non è necessario un'identità, descrivono semplicemente le operazioni dispone di identità. Si modifica un'entità denominata "trenta a cinque dollari" o sono incremento saldo di un account?
Parte della bellezza di oggetti di valore è che cui descrivere le proprietà di entità in modo molto più elegante e rivelare intento. Denaro, un oggetto di valore comune, è molto meglio come parametro di funzione di un trasferimento di fondi API rispetto un decimale. Quando si campione in un metodo di interfaccia o entità, è possibile conoscere ciò che sta gestione immediatamente.
Gli oggetti di valore non sono modificabili. Sono grado di modifica dopo che sono creati. Perché è importante che siano immutabili? Gli oggetti di valore, si sta la ricerca di funzioni effetto collaterale, liberare, ma un altro concetto prestito da DDD. Quando si aggiunge di € 20 € 20, si modifica € 20? No, si crea un nuovo descrittore di denaro di € 40. In C# è possibile utilizzare la parola chiave di sola lettura nei campi pubblici per applicare immutabilità del e funzioni effetto collaterale, liberare, come illustrato nella Figura 2 .
Nella Figura 2 Utilizzo di sola lettura per applicare l'immutabilità del
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
}
Directory principali aggregazione combina entità
Una radice di aggregata è un tipo speciale di entità che i consumer fa direttamente riferimento a. Identificare le radici di aggregazione consente di evitare over-coupling gli oggetti che compongono il modello da applicando alcune semplici regole. Si noti che le radici aggregazione guardia loro sub-entities zealously.
La regola più da tenere a mente è che radici di aggregazione sono il solo tipo di entità a cui il software può mantenere un riferimento. In questo modo evitare il grande pallina di Mud perché ora ha un vincolo che impedisce la creazione di un sistema strettamente ridotto in cui tutto ciò che ha un'associazione a tutti gli altri.
Si supponga che si dispone di un'entità denominata criterio. I criteri, ottenere rinnovati su un termine annuo, in modo che è probabile che un'entità denominata periodo. Poiché un periodo non può esistere senza un criterio e può agire periodi mediante criteri, dei criteri sono detta una radice di aggregata ed periodo è un elemento figlio dello stesso.
Mi piace il radici aggregazione solo stabilire per me. Prenda in considerazione questo codice utente l'accesso a una radice di aggregata dei criteri:
Policy.CurrentPeriod().Renew()
Sono cercando di rinnovare una polizza di assicurazione, richiamare il diagramma classi del dominio principale della gestione della polizza assicurativa. Si noti come è possibile dotting il modo per il comportamento che desidera richiamare?
Vi sono un paio di problemi con questo approccio. In primo luogo, sono violazione chiaramente il diritto Demeter. Un metodo M di un oggetto O deve richiamare solo i metodi dei seguenti tipi di oggetti: stesso, i relativi parametri, tutti gli oggetti crea o si crea un'istanza di o relativi oggetti componente diretto.
Non È completa dotting di tipo semplice? IntelliSense è una delle funzionalità più utili, coolest di Visual Studio e altri IDE moderno, ma quando si avvia dotting modo alla funzione che si desidera effettivamente richiamare, sta Introduzione associazione nel sistema non necessari. Nell'esempio precedente sono ora dipende la classe di criteri e la classe periodo.
Per ulteriormente la lettura, Brad Appleton ha un eccellente articolo disponibile sul suo sito in cui vengono illustrate le implicazioni avanzate, theories, tooling e caveats attorno il Diritto di Demeter.
Cliche death da Taglia una 1000 è una descrizione valida del potenziale nightmare di manutenzione di un sistema eccessivamente ridotto. Quando si creano riferimenti inutili tutto tramite la posizione, si crea anche un modello rigido in cui le modifiche in un'unica posizione causano una catena di modifiche tutto sul codice consumer. È possibile eseguire lo stesso scopo con, riferisce portata sto, un po'più espressivi di codice:
Policy.Renew()
Vedere come la funzione di aggregazione solo figure uscita? Internamente è possibile trovare il periodo corrente e o meno già un periodo di rinnovo e qualsiasi altra cosa sarà necessario per eseguire.
È possibile trovare quando sono unit test del mia radici aggregazione utilizzando una tecnica, ad esempio sviluppo Behavior-Driven (BDD), verso il paradigma più casella nera e test di stato una tendenza il test. Directory principali di aggregazione e le entità spesso costretti come computer di stato e il comportamento corrispondente di conseguenza. È possibile terminare i con la convalida dello stato, addizione e sottrazione. Non c'è abbastanza un po'di comportamento in corso nell'esempio riportato rinnovo nella Figura 3 ed è molto deselezionare come è possibile esprimere questa in uno stile BDD di test.
Directory nella Figura 3 test informazioni principali
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));
}
}
Dominio servizi modello principale operazioni
In alcuni casi è disporre operazioni o processi che non dispongono un'identità o il ciclo di vita del dominio. Servizi di dominio consentono di uno strumento per la modellazione questi concetti. Sono in genere prive di stato e altamente coerente, spesso fornire un unico metodo pubblico e a volte un overload per agire sugli insiemi.
MI piace utilizzare i servizi per alcuni motivi. Quando sono presenti un numero di dipendenze di partecipano a un comportamento e non è disponibile un luogo naturale su un'entità per inserire questo comportamento, utilizzerò un servizio. Quando la lingua connettività equipe relative a un processo o l'operazione come un concetto di ordine prima, verrà domanda se un servizio senso come punto centrale di orchestrazione per il modello.
È possibile utilizzare un servizio di dominio nel caso di rinnovo. Si tratta di uno stile alternativo. Anziché il metodo per inserire un IAuditNotifier direttamente nel metodo del metodo di rinnovo l'entità di criteri, è possibile estrarre un servizio di dominio per gestire risoluzione delle dipendenze per noi, ma più naturale per noi risolvere un servizio di dominio da un contenitore IOC a un'entità. Questa strategia senso molte più a me quando sono presenti più dipendenze, ma verrà presenterò l'alternativa comunque.
Qui è un breve esempio di un servizio di dominio:
public class PolicyRenewalProcesor {
private readonly IAuditNotifier _notifier;
public PolicyRenewalProcessor(IAuditNotifier notifier) {
_notifier = notifier;
}
public void Renew(Policy policy) {
policy.Renew();
_notifier.ScheduleAuditFor(policy);
}
}
Il servizio di parola è un termine altamente Overload nel mondo sviluppatore. RITENGO che in alcuni casi del servizio come nell'architettura orientata ai servizi (SOA, Service Oriented ARCHITECTURE). Gli altri casi che è possibile considerare servizi come poco classi che non rappresenta una particolare persona, luogo o cosa nell'applicazione, ma che tendono a embody processi. Servizi di dominio è in genere rientrano in questa categoria di quest'ultimo. Tendono a essere denominato verbi o attività dell'azienda che introducono dominio esperti del linguaggio di connettività.
Servizi dell'applicazione, è invece, rappresentano un modo ottimo per introdurre un'architettura a livelli. Utilizzarli per il mapping dati all'interno il modello di dominio a una forma richieste da un'applicazione client. Ad esempio, è possibile che si desidera visualizzare dati tabulari in un DataGrid, ma si desidera mantenere un grafico di granularità e matrici di oggetti nel modello.
Servizi dell'applicazione sono inoltre molto utili per l'integrazione di più modelli, ad esempio, la conversione tra flusso di Criteri controllo base criterio lavoro e. Allo stesso modo, è possibile utilizzare li per portare le dipendenze di infrastruttura in combinazione. Si supponga uno scenario comune in cui si desidera esporre il modello di dominio con Windows Communication Foundation (WCF). Sarebbe utilizzare un servizio dell'applicazione decorato con gli attributi WCF per rendere questo accada anziché consentendo di perdita di WCF nel modello di dominio pure.
Servizi dell'applicazione tendono a essere molto vasta e dei riferimenti, installando ad esempio funzionalità coerente. Considerare l'interfaccia e implementazione parziale che vedere nel codice nella Figura 4 un buon esempio di un servizio dell'applicazione.
Figura 4 A semplice Application Service
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);
}
}
Archivi Salva e lavorare informazioni delle directory principali
Cui passa per recuperare entità Come si memorizzarli? Queste domande sono risposta per il criterio di archivio. Archivi rappresentano un insieme in memoria e consigli convenzionali sono che fine un repository per il primo livello di aggregata.
Archivi sono un buon candidato per una super classe o fa cosa Martin Fowler riferimento a come il motivo supertipo layer. Utilizzando i generics per derivare un'interfaccia di base archivio dall'esempio precedente è una questione semplice:
public interface IRepository<T>
where T : IEntity
{
Find<T>(int id);
Find<T>(Query<T> query);
Save(T entity);
Delete(T entity);
}
Archivi impedire i concetti di database o persistenza, ad esempio istruzioni SQL o stored procedure da commingling con il modello e di modificare è di importanza a disponibili: acquisizione del dominio.Questa separazione del codice del modello dall'infrastruttura è un attributo valido.Vedere la barra laterale "livelli Anti-Corruption" per una descrizione più dettagliata.
A questo punto, probabilmente notato che non sto parlando le radici come aggregazione nelle entità subordinate e in modo gli oggetti di valore collegati effettivamente ottenere permanente su disco.Si tratta intenzionale.Salvataggio dei dati richiesto per eseguire comportamento nel modello riguarda ortogonale al modello stesso.Persistenza è infrastruttura.
Un sondaggio di queste tecnologie esula molto dall'ambito di un'introduzione alla DDD.Basti ma che sono disponibili numerose opzioni adatte e maturo per la memorizzazione dei dati del modello dal Framework ORM (Object-relazionale mapping) ai database di documenti di dati "rullo-nome-proprietario" mappers negli scenari più semplici.
DDD risorse
Nord Dan su come struttura utente Stories
Il grande pallina di Mud stile architetturali
Blog di Greg Young su CodeBetter
Robert c.Formato del Paolo sul singolo criterio di responsabilità
Brad Appleton sul diritto di Demeter
Martin Fowler descrive il modello di supertipo livello
Robert c.Paolo sul S.O.L.I.D.Principi
La cosa con database
Da questo punto sono che è stato considerato " è tutti ben e buona, Dave.Ma in cui salvare l'entità?" Sì, sarà necessario gestire con questo dettaglio importante, ma come o in cui mantenere i modelli è principalmente tangential per una panoramica delle DDD.
Un numero di sviluppatori o amministratori di database verrà creata l'asserzione che il database sia il modello.In molti casi, è parzialmente true.Database, mentre altamente normalizzato visualizzata con uno strumento per la creazione di diagrammi possono comunicare un lotto sulle informazioni e le relazioni nel tuo dominio.
Dati di modellazione come una tecnica principale lascia per essere necessario, tuttavia.Quando si desidera conoscere i comportamenti inerenti nello stesso dominio, tecniche solo i dati come entità-relazione diagrammi (ERDs) o i modelli di entità-relazione e suddividere diagrammi delle classi.È necessario visualizzare parti l'applicazione in movimento e come tipi di collaborare per ottenere il lavoro svolto.
Quando è modellizzazione, spesso raggiungere per diagrammi di sequenza su una lavagna come strumento di comunicazione.Questo approccio acquisisce gran parte l'essenza di comunicazione di una struttura comportamento o un problema senza la cerimonia di Unified Modeling Language (UML) o Architettura basato su modelli.MI piace evitare inutile cerimonia, soprattutto quando per cancellare i diagrammi che è possibile inserire nella lavagna.È possibile non preoccuparsi circa 100 % la conformità UML nei diagrammi di preferenza semplici caselle, frecce e lanes di nuoto possibile tracciare rapidamente.
Se non si già utilizzano diagrammi di sequenza del proprio team, consigliabile formazione tecnica.È osservato l'effetto potente durante il recupero ritiene che i membri del team tramite problemi attorno all'architettura a livelli, SRP progettazione comportamento modellazione dei dati e dell'architettura pensare in generale.
Guida introduttiva a DDD
Diventare esperto con programmazione orientata non è portata semplice.Ritiene che la competenza è all'interno il reach più professionale gli sviluppatori, ma ha dedication, formazione libro e pratica, pratica e più pratica.Consente inoltre se adottare una tue emozioni craftsmanship e formazione continuo.
Come si iniziare?In poche parole: effettuare il compiti.Informazioni sulle operazioni come laS.O.L.I.D.principie studiare libro degli Alboni Eric.L'investimento di tempo più costituiranno per se stessa.InfoQ ha prodotto una versione più piccola del libro DDD che introduce alcuni concetti fondamentali.Se si è su un budget contabile o temporale o semplicemente in modalità di analisi, È consigliabile avviare è.Una volta che viene visualizzato un footing a tinta unita, vagare su per ilYahoo!DDD gruppoPer visualizzare quali problemi del fellow progettisti ancora con e ottenere partecipano alla conversazione.
DDD non è un nuovo doctrine o metodologia.Si tratta di un insieme di strategie time-tested.Quando si ottiene per l'esercitazione, provare a adattamento tali philosophies, tecniche e modelli che senso la maggior parte nella situazione.Alcuni elementi del DDD applicano più universalmente rispetto ad altri.Comprendere il motivo per esistenza il dominio principale uncovering e utilizzando il linguaggio di connettività e identificando i contesti in cui si sta modellazione sono modo più importanti da nailing tale archivio perfettamente opaco e one-size-fits-all.
Quando si progetta le soluzioni, progettare per valore.Se le finestre di progettazione producono immagini e gli sviluppatori sono un tipo di finestra di progettazione, il supporto deve essere il valore aziendale.Valore consciousness supera considerazioni, ad esempio la conformità a dogma e scelta della tecnologia di persistenza, importante queste scelte sembrano a volte.
Laribee Dave coaches il team di sviluppo del prodotto in VersionOne.È oratore eventi sviluppatore locali e nazionali ed è stato conferito architettura Microsoft MVP per 2007 e 2008.Ha scritto sulla rete di blog CodeBetter inthebeelog.com.