Entity Framework and Domain Driven Design

4,787 views

Published on

Given at Oredev 2013 (Nov 2013 in Malmo Sweden). This presentaiton is about the intersection of Entity Framework (EF ) and Domain Driven Design (DDD) and gives pointers about *not* worrying about EF when implementing your domain in code and what you can expect when it's time to implement the persistence layer. There is a video of me giving this presentation on Vimeo at http://vimeo.com/78893724

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,787
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • Focus on repo on this slide, then use code samples to quickly show difference between code that uses context directly and code that uses a repository, also show unit of work encapsulating a transaction possibly sharing reposPoints to make about demo ware…controller has direct access to /dependeny on EF. Need to know ins and outs of EF, linq to EF etc to get and update the data you want. Changes to data access logic may have direct impact on controller code which then needs to be modified. That may impact the UI code. That’s just the beginning of the problems.
  • Entity Framework and Domain Driven Design

    1. 1. @JulieLerman Øredev 2013 ThankyouMarkRothko Entity Framework Domain Driven Design
    2. 2. My Two Worlds
    3. 3. D is for Domain not Persistence
    4. 4. Database Inspired
    5. 5. UI LINQ Logic Database
    6. 6. Separation of Concerns Maintainable Adaptable Testable Extensible Organized
    7. 7. *** Driven Development Business ProblemSoftware Solution Code OCD
    8. 8. Business/Domain Layer Repository/Unit of Work Infrastructure/Data Model ORM/Entity Framework Database UI Service Layer LINQ Tests Tests
    9. 9. Domain Models Services Data Layer Repositories Domain Events Infrastructure
    10. 10. Considering the Domain Customers Sales Orders Products Payments Shipments Shippers Promotions SalesPeople Employees SalaryHistory Returns Typical Model/DbContext
    11. 11. DDD Bounded Contexts for Application Subsystems Customer Service Order Taking Billing Returns Marketing Human Resources Shipping
    12. 12. Focused DbContexts Products Promotions Customers SalesPeople Employees SalaryHistory Returns Orders Customers Payments Orders Customers Customer Service Orders Customers Billing Returns Marketing Human Resources Shipments Shippers Shipping Orders DB DB Order Taking
    13. 13. Focused DbContexts Products Promotions SalesPeople Employees SalaryHistory Returns Orders Payments Orders Customer Service Orders Billing Returns Marketing Human Resources Shipments Shippers Shipping Orders Customers Customers Customers Customers Order Taking DB DB
    14. 14. Rich Domain Models Anemic Domain Models
    15. 15. PRIVATE SETTERS PUBLIC METHODS
    16. 16. DDD is for solving Complex Problems. Quite often, CRUD is enough
    17. 17. Value Objects
    18. 18. EF & DDD Value Objects EF Complex Types • No Identity Key • Property of Entity/other Complex Type • Maps to columns of parent entity/entities DDD Value Object • No Identity Key • Immutable • Equality compares all values • No Side-Effects
    19. 19. Do You Need a Persistence Model? Entity Framework/Queries/Commands Domain Model Persistence Model Payments Invoices Customers DB Mappings, DB concerns, Follow EF rules Domain Model Payments Credit Invoice Payee Payments Credit Invoice Payee Credits
    20. 20. Many variations… One repo per type? Read repos? Write repos? One repo per object graph? One repo per context ?
    21. 21. Testing with EF in the Mix • EF only or Database? • Using database: DropCreateDatabaseAlways Integration/ Tests • No EF involved: Inconsequential • EF in the way: Abstraction/Interfaces Unit Tests
    22. 22. Replace EF Behavior in Tests Mocking Frameworks • Learning Curve • Magic • DbSets are not always supported Roll Your Own Fakes • Learning Curve • More coding effort • Educational EF6 More Easily Supports Mocks • DbSet has new features • Chose not to enhance IDbSet to match • Instead, DbSet is more mockable • Protected constructor has no ties to DbContext
    23. 23. DDD += EF • Focus on Domain • Map to persistence later • EF can resolve most DDD patterns • Some tweaks may be required • Consider separate persistence model in more complex scenarios
    24. 24. Coming Soon Domain Driven Design course
    25. 25. Resources • Coding for Domain-Driven Design: Tips for Data-Focused Devs Part 1-3 MSDN Mag Data Points Column August 2013, Sept 2013, October 2013 • Pluralsight On-Demand Training: pluralsight.com • MSDN Developer Center: msdn.com/data/ef • EF Team: blogs.msdn.com/adonet • LearnEntityFramework.com • Programming Entity Framework: DbContext • by Julie Lerman and Rowan Miller, O’Reilly Media, Feb 22 2012 • Domain Driven Design By Eric Evans, Addison-Wesley, 2004 • Implementing Domain Driven Design, A-W, Vaughn Vernon, 2013 • domaindrivendesign.org
    26. 26. consultant/mentor Microsoft MVP, INETA Speaker, ASPInsider, MCP, VTdotNET Leader contact jlerman@theDataFarm.com www.thedatafarm.com blog theDataFarm.com/blog twitter @julielerman book web site LearnEntityFramework.com Contact Info (40% off at O’Reilly booth)
    27. 27. Mark Rothko 1903 - 1970

    ×