1. Domain-Driven Design using the ADO.NET Entity Framework Tim McCarthy Principal Engineer, InterKnowlogy timm@interknowlogy.com

2. About… InterKnowlogy (www.InterKnowlogy.com) www.InterKnowlogy.com Tim McCarthy, Principal Engineer Custom App Dev / Consulting / Software Engineering Firm headquartered in Carlsbad, CA Microsoft Gold Partner managed in SoCal and Redmond Design, Architect, Build and Deploy enterprise class applications Industry Experts: 90% of the company is published Microsoft ®.NET Application development for 5+ years! Microsoft ®.NET Smart Client pioneers / industry leaders Information Worker Solutions Integration / Messaging, B2B / B2C, Wireless / Mobility Microsoft ® SharePoint, Microsoft ® BizTalk ® Web Services, Microsoft ® Active Directory ®, Security, SSO, Authorization, Authentication Solutions on the emerging Microsoft servers Largest Client: Microsoft

3. Agenda Organizing Domain Logic What is DDD? Why Domain-Driven Design (DDD)? DDD Definitions/Patterns ADO.NET Entity Framework When is DDD appropriate?

4. Organizing Domain Logic Transaction Script Domain Model Table Module

5. Choosing the Right Approach

6. Demo: Organizing Domain Logic

7. What is DDD?

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

9. Ubiquitous Language Common terms between business experts and development team Use the language in your code Namespaces Class, property, method, variable names

10. Communicating the Language Create whiteboard drawings Favor whiteboarding over Visio Use digital camera to capture, then paste into Word Use Visual Studio class diagrams for core parts of the domain Code and diagram are kept in sync No wasted time diagramming, your diagram is the code

11. Definition: Entities An object defined primarily by its identity Not its attributes Could be a person, a customer, an order, etc. Not all objects have meaningful identities… In some systems, a class may be an ENTITY, in others maybe not

12. Definition: Value Objects Represent an aspect of the domain with NO conceptual identity Use when you care about what something is, not who they are Same thing as a DTO [Fowler PoEAA] Simple, immutable objects

13. Definition: Aggregates A cluster of associated objects treated as a unit for the purpose of data changes They have a root and a boundary Boundary = what is inside the AGGREGATE Root = single ENTITY inside the AGGREGATE Most important concept to understand in modelling!

14. Aggregate Rules The root ENTITY has global identity ENTITIES inside the boundary have local identity Nothing 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 roots …a few more

15. Definition: Services An operation offered as an interface that stands alone in the model Does not fit into any of the objects in the model Stateless To be used judiciously (do not turn your app into a Transaction Script) Use when an operation is an important domain concept

16. 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 ENTITIES Example: a common Id property Helps eliminate duplicate code

17. Pattern: Repository Provide access to AGGREGATE roots Represents 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!

18. Pattern: Layered Architecture

19. Infrastructure Persistence Strategies Remember, Domain Model is Persistent Ignorant! Approaches Custom Manual Code Code Generation Metadata Mapping (O/R Mapping)

20. ADO.NET Entity Framework: Goals Raise abstraction Level for Data Programming Get Rid of the Plumbing

21. ADO.NET Entity Framework Provides Mapping from relational data to.NET classes Auto-generation of both mapping and entities Uses a New Data Provider The EntityClient Provider Supports Querying over entities Relationship navigation Entity Inheritance

22. ADO.NET Entity Framework: Metadata Structure

23. Demo: Entity Framework

24. Entity Framework: Impressions Great Hope for the future, but Pain for the present EDM designer not there yet (after Orcas) Does not currently support Persistence Ignorance, but the team is working on it Rich change-tracking support

25. DDD Revisited…

26. When is DDD Appropriate “If 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

27. 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

28. Tim McCarthy, InterKnowlogy Get the Demos & PPT at: Blogs.InterKnowlogy.com/TimMcCarthy More info on InterKnowlogy: www.InterKnowlogy.com Contact me: Tim McCarthy E-mail : TimM@InterKnowlogy.com Phone: 760-930-0075 x205 About Tim McCarthy.NET Architect/Dev Lead/Trainer Author / Speaker MCSD, MCSD.NET, MCDBA, MCT, IEEE CSDP