Domain Driven Design: Overview Speaker: Giancarlo Sudano

Publish in

Documents

4 views

Please download to get full document.

View again

of 44
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Share
Description
Domain Driven Design: Overview Speaker: Giancarlo Sudano. About me:. Giancarlo Sudano ( alias janky ). Software Architect in Objectway Fondatore di GUISA www.guisa.org Blog su Ugidotnet: http://blogs.ugidotnet.org/janky Email: giancarlo.sudano@gmail.com giancarlo.sudano@objectway.it.
Transcript
Domain Driven Design: OverviewSpeaker: Giancarlo SudanoAbout me:Giancarlo Sudano(aliasjanky)Software Architect in ObjectwayFondatore di GUISA www.guisa.orgBlog su Ugidotnet: http://blogs.ugidotnet.org/jankyEmail: giancarlo.sudano@gmail.comgiancarlo.sudano@objectway.itAgenda
  • Domain Model
  • Domain Driven Design
  • Conceptual Map
  • Layering
  • Esempi reali: Web Client Software Factory
  • DOMAIN MODELUn po di discipline...Business RequirementBusiness RequirementUse Case ModelProcesso di vendita(testo)Processo d’Ordine(testo)Business ModelingBusiness RequirementBusiness ModelingUse Case ModelDomain Model1OrderCustomerProcesso di vendita(testo)Processo d’Ordine(testo)1..*1..*ProductGli Use case, i termini, i concetti ispirano il Domain ModelSoftware DesignBusiness ModelingSoftware DesignDomain ModelObject Model1OrderCustomer1..*1..*ProductI concetti del Dominio ispirano nomi e comportamenti delle classi del softwareDesign del Domain LayerClassificazione fatta da Fowler [PoEAA 2004]Transaction Script: Principalmente il layer sarà modellato con delle procedure che prendono l’input dal layer di presentation, li processano e eventualmente trasmettono manipolazioni sui database.Table Module: Serie di classi che gestiscono la logica di business per tutte le righe sul database di una particolare entità. Domain Model: Serie di classi ispirate al modello analitico che gestiscono sia stato che comportamento. Una singola istanza rappresenta una singola entità.Riepilogo delle definizioni
  • Modello analitico: concettualizzazione del problema di business
  • Domain Layer: Strato di software che rappresenta l’implementazione del modello analitico
  • Domain Layer patterns: metodologie per implementare i problemi di business
  • Transaction script
  • Table Module
  • Domain Model
  • Domain Driven DesignFormalizzazione fatta da Eric Evans 2003/04 nel suo libro “Domain Driven Design: Tackling Complexity In The Heart Of Software”Scopo del libro:“…To describe and build a vocabulary about the very art of domain modeling…”...tutto cominciò...http://domaindrivendesign.orgInformazioni IntervisteArticoliDiscussioniCase StoriesEsempiDomain Driven Design: Il portaleLa DDD è un mindset, cioè una serie di principi e priorità, atte ad accelerare la progettazione software che ha a che fare con domini di particolare complessità.Domain Driven Design: DefinizioneIl modello analitico (cioè il risultato del lavoro degli analisti) è uno strumento di sola comprensione. Un analista poi può usare UML per la visualizzazione del modello stesso.  Il modello non porterà nessun dettaglio implementativo ai fini di non inquinare la comprensione.Presupposti per la nascita di DDDl'implementazionedi un modello molte volte può allontanarsi notevolmente dalla sua iniziale descrizione.La Domain Driven Design è una disciplina di progettazione atta quindi a tenere costantemente vicini/connessi il modello analitico che il modello implementativo. Quindi...Esempio classico di discostamentoLa prima Conceptual Map di DDDEntity e ValueObjectTroppa logica nelle entity?
  • In generale si tende ad aggiungere solo i metodi essenziali ad una entity.
  • Inserire troppa logica all’interno di una entity:
  • + Complessità
  • Manutenibilità
  • Chiarezza, Espressività
  • ServiceUna classe Service modella, non tanto una entità di dominio, ma una regola di businessQualcosa che il software “deve fare” (operazione) e che non necessariamente coincide con uno statoBusiness RulesRestrictions: Un cliente non può inserire più di tre richieste d’ordine caricate sul suo credit account. Heuristics: Gli ordini di un cliente con uno stato preferenziale verranno evasi immediatamente. Computations: Il volume di ordini annuale di un cliente deve essere calcolato dal totale delle vendite chiuse entro la chiusura dell’anno fiscale aziendale. Inference: Un cliente deve essere considerato preferenziale se ha almeno 5 ordini superiori a 1000 euro. Timing: Un cliente verrà archiviato se non effettua ordini per 36 mesi consecutivi. Triggers:Quando un ordine è stato spedito, una notifica di “Send advance” deve essere notificata ad una serie di sottoscritti Tipi di ServicesCome distribuire logica tra Service e Entity?
  • Una Entity con troppe responsabilità rischia di perdere in chiarezza concettuale.
  • Entity troppo cariche sono di difficile manutenzione, refactoring e testing.
  • Le operazioni di business, sono spesso legate ad altre entity. Esprimere queste operazioni come metodo di una Entity, aumenta la sua dipendenza da altri oggetti
  • Service dipendenti da classi (non da id)FactoryResponsabilità di creare e assemblare oggetti particolarmente complessi.La logica di creazione di grafi immersa nel costruttore stesso, potrebbe non essere una “buona idea”.RepositoryResponsabilità del ciclo di vita delle Entity.Responsabilità infrastrutturali di persistenza quali Identity Map, Cache.LayeringContesto classico
  • Isolare il codice dalla interfaccia utente
  • Isolare il codice di accesso al database
  • Soluzione classicaPresentationBusiness LogicData AccessSoluzione classicaWinFormCompact FrameworkWeb FormWPF FormBusiness LogicData Access(database A)Data Access(database B)Non se ne può più...andiamo oltre DominioDomain Model quanto più indipendente da tutte le altre parti del sistema. E’ buona norma rendere il DM facilmente testabile, modificabile.Minimizzare la dipendenza anche dalle API di .NET. Presentation LayerRiutilizzo più pesante del codice tra una Presentation Layer ed un altroMigliorare le capacità di Test delle View e della logica di FlussoServizi:Distinzione tra servizi infrastrutturali e applicativiRequisiti più altiIsolamento: LayeringUser Interface (Presentation Layer)Responsible for presenting information to the user andinterpreting user commands.Application LayerThis is a thin layer which coordinates the applicationactivity. It does not contain business logic. It does nothold the state of the business objects, but it can holdthe state of an application task progress.Domain Layer This layer contains information about the domain. Thisis the heart of the business software. The state ofbusiness objects is held here. Persistence of thebusiness objects and possibly their state is delegated tothe infrastructure layer.Infrastructure LayerThis layer acts as a supporting library for all the otherlayers. It provides communication between layers,implements persistence for business objects, containssupporting libraries for the user interface layer, etc.SoluzionePresentationCoordina le attività dell’applicazione.Non contiene logica di business.Non gestisce lo stato delle Entity, ma gestisce lo stato dell’applicazione e dei progresso dei taskPuò eseguire Processi di Business e Servizi in seguito a comandi dalla UI o a Eventi Esterni UI ProcessBusiness LogicData AccessConfusioni sui nomi di layer?Martin FowlerDNA, J2EEBrownEric EvansPresentationPresentationPresentationPresentationPresentation=UI Process...Controller/MediatorApplication ControllerApplication=BusinessBusinessDomainDomainDomain=Data AccessData AccessData AccessData SourceInfrastructure=SoluzionePresentationUI Process Business Process Security ServiceAltri ServiceBusiness RulesValidationsData AccessEntity (detto anche Core)SoluzionePresentationUI Process Business Process Security ServiceAltri ServiceBusiness RulesValidationsData AccessEntity (detto anche Core)Layered ApplicationsService GatewayCrossCutting Utility ClassException Handling, Logging, SecurityPresentation LayerUserInterface Process LayerCAB , CWAB, Acropolis , MonoRail, Workflow FoundationAuthorizationAuthenticationBusiness Process LayerWorkflow Foundation, BizTalk, Spring Validation, Validation Application BlockDomain LayerAOP FrameworkSpring.net, Policy Injection Application BlockLog e TraceTransaction ManagementDataAccess LayerService LayerDependency Injection Framework(Spring.NET, Windsor)ORM NHibernate, Linq to SQL, GenomeLegacyWebServicesLDAPEnterpriseServicesDatabaseAltre navigation mapsSupple Design PatternsEric Evans: Domain Driven Design [2006]Model Integrity PatternsEric Evans: Domain Driven Design [2006]Libro: Domain Driven Design: Tackling Complexity In The Heart Of Software [Eric Evans 2003]Libro: Applying Domain-Driven Design and Patterns [Jimmy Nilsson 2006]Libro: Domain Driven Design Quickly [InfoQ 2006] (gratuito, scaricabile da internet)http://domaindrivendesign.org/Seguite il mio blog:iniziativa: “Domain Model e Enterprise Application”Riferimenti
    Related Search
    We Need Your Support
    Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

    Thanks to everyone for your continued support.

    No, Thanks