domain-driven design using the ado.net entity framework tim mccarthy principal engineer,...

of 28 /28
Domain-Driven Design Domain-Driven Design using the ADO.NET using the ADO.NET Entity Framework Entity Framework Tim McCarthy Tim McCarthy Principal Engineer, Principal Engineer, InterKnowlogy InterKnowlogy [email protected] [email protected]

Author: amos-ramsey

Post on 11-Jan-2016

217 views

Category:

Documents


2 download

Embed Size (px)

TRANSCRIPT

  • Domain-Driven Designusing the ADO.NET Entity FrameworkTim McCarthyPrincipal Engineer, [email protected]

  • AboutInterKnowlogy (www.InterKnowlogy.com)Tim McCarthy, Principal EngineerCustom App Dev / Consulting / Software Engineering Firm headquartered in Carlsbad, CAMicrosoft Gold Partner managed in SoCal and RedmondDesign, Architect, Build and Deploy enterprise class applications Industry Experts:90% of the company is publishedMicrosoft .NET Application development for 5+ years!Microsoft .NET Smart Client pioneers / industry leadersInformation Worker SolutionsIntegration / Messaging, B2B / B2C, Wireless / Mobility Microsoft SharePoint, Microsoft BizTalk Web Services, Microsoft Active Directory, Security, SSO, Authorization, AuthenticationSolutions on the emerging Microsoft serversLargest Client: Microsoft

  • AgendaOrganizing Domain LogicWhat is DDD?Why Domain-Driven Design (DDD)?DDD Definitions/PatternsADO.NET Entity FrameworkWhen is DDD appropriate?

  • Organizing Domain LogicTransaction ScriptDomain ModelTable Module

  • Choosing the Right Approach

  • Demo: Organizing Domain Logic

  • What is DDD?

  • Why Domain-Driven Design (DDD)?Most development time is still spent writing plumbing code instead of business logicTypically, the UI will change a LOT more than the business logicThe model is a great tool for communication between developers and users.NET has good support for it!

  • Ubiquitous LanguageCommon terms between business experts and development teamUse the language in your codeNamespacesClass, property, method, variable names

  • Communicating the LanguageCreate whiteboard drawingsFavor whiteboarding over VisioUse digital camera to capture, then paste into WordUse Visual Studio class diagrams for core parts of the domainCode and diagram are kept in syncNo wasted time diagramming, your diagram is the code

  • Definition: EntitiesAn object defined primarily by its identityNot its attributesCould be a person, a customer, an order, etc.Not all objects have meaningful identitiesIn some systems, a class may be an ENTITY, in others maybe not

  • Definition: Value ObjectsRepresent an aspect of the domain with NO conceptual identityUse when you care about what something is, not who they areSame thing as a DTO [Fowler PoEAA]Simple, immutable objects

  • Definition: AggregatesA cluster of associated objects treated as a unit for the purpose of data changesThey have a root and a boundaryBoundary = what is inside the AGGREGATERoot = single ENTITY inside the AGGREGATEMost important concept to understand in modelling!

  • Aggregate RulesThe root ENTITY has global identityENTITIES inside the boundary have local identityNothing outside the AGGREGATE boundary can hold a reference to anything inside, except to the root ENTITY Objects in the AGGREGATE can hold references to other AGGREGATE rootsa few more

  • Definition: ServicesAn operation offered as an interface that stands alone in the modelDoes not fit into any of the objects in the modelStatelessTo be used judiciously (do not turn your app into a Transaction Script)Use when an operation is an important domain concept

  • Pattern: Layered Supertype [Fowler 475]Type that acts as the supertype for all types in its layer, i.e. a base class!Factors out common features, such as handling the identity of ENTITIESExample: a common Id propertyHelps eliminate duplicate code

  • Pattern: RepositoryProvide access to AGGREGATE rootsRepresents all objects of a certain type as a conceptual set (usually emulated)Behaves like a collection, e.g. Add(), Remove(), FindBy(id), etc.Persistence Ignorance!

  • Pattern: Layered Architecture

  • Infrastructure Persistence StrategiesRemember, Domain Model is Persistent Ignorant!ApproachesCustom Manual CodeCode GenerationMetadata Mapping (O/R Mapping)

  • ADO.NET Entity Framework: GoalsRaise abstraction Level for Data Programming

    Get Rid of the Plumbing

  • ADO.NET Entity FrameworkProvidesMapping from relational data to .NET classesAuto-generation of both mapping and entitiesUses a New Data ProviderThe EntityClient ProviderSupportsQuerying over entitiesRelationship navigationEntity Inheritance

  • ADO.NET Entity Framework: Metadata Structure

  • Demo: Entity Framework

  • Entity Framework: ImpressionsGreat Hope for the future, but Pain for the presentEDM designer not there yet (after Orcas)Does not currently support Persistence Ignorance, but the team is working on itRich change-tracking support

  • DDD Revisited

  • When is DDD AppropriateIf an unsophisticated team with a simple project decides to try a model-driven design with layered architecture, it will face a difficult learning curve. ... The overhead of managing infrastructure and layers makes very simple tasks take longer. Simple projects come with short time lines and modest expectations.

    Domain-Driven Design by Eric Evans, p76

  • Resources[Evans]: Domain-Driven Design: Tackling Complexity in the Heart of Software, Evans, Addison-Wesley (2003)[Fowler]: Patterns of Enterprise Application Architecture, Fowler, Addison-Wesley (2003)[Nilsson]: Applying Domain Driven Design and Patterns: using .NET

  • Tim McCarthy, InterKnowlogyGet the Demos & PPT at:Blogs.InterKnowlogy.com/TimMcCarthyMore info on InterKnowlogy:www.InterKnowlogy.com Contact me: Tim McCarthyE-mail: [email protected]: 760-930-0075 x205About Tim McCarthy.NET Architect/Dev Lead/TrainerAuthor / SpeakerMCSD, MCSD.NET, MCDBA, MCT, IEEE CSDP

    MGB 2003 2003 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.*MGB 2003 2003 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.*MGB 2003 2003 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.*One of the most important, yet often forgot, aspects of enterprise applications is the domain logic. These are the business rules, validations, and calculations that operate on the data as it is brought into an information system or displayed by it. For simple database filing systems there is often little or no domain logic. However for many systems there is often quite complex domain logic, and this logic is subject to regular change as business conditions change.

    Transaction Script a procedure that takes the input from the UI, processes it (validations, calculations, etc.), stores data in a data store (usually a database), and invokes operations from other systems. Most business applications can be thought of as a series of transactions. A transaction may view some information as organized in a particular way, another will make changes to it. Each interaction between a client system and a server system contains a certain amount of logic. In some cases this can be as simple as displaying information in the database. In others it may involve many steps of validations and calculations.

    A Transaction Script organizes all this logic primarily as a single procedure, making calls directly to the database or through a thin database wrapper. Each transaction will have its own Transaction Script, although common subtasks can be broken into sub-procedures.

    Domain Model instead of having a routine that has all of the logic for a user action, each object takes a part of the logic thats relevant to it. Incorporates behavior and data. At its worst business logic can be very complex. Rules and logic describe many different cases and slants of behavior, and it's this complexity that objects were designed to work with. A Domain Model creates a web of interconnected objects, where each object represents some meaningful entity, whether as large as a corporation or as small as a single line on an order form.

    The advantage of the domain model is that the logic needed for any particular operation is loosely coupled across the objects rather than being contained in a single method. This pattern tends to view the application as a set of interrelated objects. Table Module - A single instance that handles the business logic for all rows in a database table or view. A Table Module organizes domain logic with one class per table in the data-base, and a single instance of a class contains the various procedures that will act on the data. The primary distinction with Domain Model (116) is that, if you have many orders, a Domain Model (116) will have one order object per order while a Table Module will have one object to handle all orders.

    MGB 2003 2003 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.*Building an object-oriented Domain Model is a popular approach to organizing domain logic. It works particularly well with complex domains. It's downside is that it is difficult to do well. These patterns describe how to think about building and structuring a rich domain model, as well as how to recognize and overcome the real-world obstacles that too-often prevent people from employing the modeling principles they know

    MGB 2003 2003 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.*Good-ole object-oriented design, but with some design rulesMGB 2003 2003 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.*MGB 2003 2003 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.*MGB 2003 2003 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.*MGB 2003 2003 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.*