SlideShare a Scribd company logo

Domain-Driven Design with ASP.NET MVC

•
•
Steven Smith
Steven Smith

This document discusses Domain-Driven Design (DDD) and how it can be applied to ASP.NET MVC projects. It covers DDD concepts like ubiquitous language, bounded contexts, entities, value objects, domain services, and domain events. It also discusses how to structure an MVC project to separate the domain model from the rest of the application using patterns like layered architecture and ports and adapters. The document argues that DDD can provide benefits like flexibility, manageable complexity, and centralized business logic, though it may require more time and effort to implement.

1 of 41
Download to read offline
Domain-Driven Designwith ASP.NET MVC Steve Smith CTO, Falafel Software @ardalis| steve.smith@falafel.com
What is Domain-Driven Design (DDD)?
Domain-Driven Design with ASP.NET MVC
Communication •Ubiquitous Language •Domain Expert Interaction Modeling •Core Domain •Generic Subdomains •Bounded Context •Context Map •Shared Kernel •Anti-Corruption Layer Implementation •Model-Driven Design •Layered Architecture •Entities •Value Objects •Services •Factories •Aggregates •Repositories •Domain Events
DDD is BIG “The more you know, the more you realize you know nothing.” Socrates
DDD Fundamentals Course •Over 4 hours of content (demos using MVC + SignalR) •http://bit.ly/PS-DDD
DDD Benefits •Flexibility •Software models customer’s understanding of problem •Breaks complexity into manageable pieces •Well-organized; easily tested •Business logic lives in one place
DDD Drawbacks •Time and Effort •Learning Curve •Overkill without Complexity •“Anemic” domain model problem
Communication “As software developers, we fail in two ways: we build the thing wrong, or we build the wrong thing.” Me
Domain-Driven Design with ASP.NET MVC
Ubiquitous Language http://upload.wikimedia.org/wikipedia/commons/2/23/Rosetta_Stone.JPG
Language “A project faces serious problems when its language is fractured.” Eric Evans
Ubiquitous Language •Ubiquitous–adjective. Present, appearing, or found everywhere. •Synonyms: pervasive, universal •Used within a given Bounded Context •Used in code, design documents, and conversations --Everywhere
DomainTerms Domain Experts Problem Domain Core Domain Sub-Domains
Bounded Contexts •Provide Separation of Concerns •Limit complexity •Should be clearly boundedand separate
Appointment Scheduling Billing
Appointment Scheduling Billing Anti- Corruption Layer
Model Driven Design Not Data-Driven
Layered Architecture •Ports and Adapters •Hexagonal •Onion
Organizing in a Solution
Entities “Many objects are not fundamentally defined by their attributes, but rather by a thread of continuity and identity.” Eric Evans
Changing Attributes Doesn’t Change Which One We’re Talking About ID:1 •Name: Steve Smith •Twitter: @ardalis •Favorite Color: Blue ID: 1 •Name: StevenSmith •Twitter: @ardalis •Favorite Color: Blue ID: 1 •Name: Steven Smith •Twitter: @ardalis •Favorite Color: Orange
Domain-Driven Design with ASP.NET MVC
Domain-Driven Design with ASP.NET MVC
Value Objects •Defined by their attributes •Immutable •Should have no side effects •Examples: strings, addresses, currency
Domain-Driven Design with ASP.NET MVC
Immutable!
Domain Services •Not a natural part of an Entity or Value Object •Interfacedefined in terms of other model elements •Should be stateless(but may have side effects)
Services in Different Layers UI Layer & Application Layer Infrastructure Domain (“Application Core”) Message Sending Message Processing XML Parsing UI Services Transfer Between Accounts Process Order Send Email Log to a File
Domain Events “Use a Domain Event to capture an occurrence of something that happened in the domain.” Vaughn Vernon Implementing Domain-Driven Design
Domain Event Tips •Consider for cases of “whenthis happens, then…” •Or “Notify someone when…” •Domain events represent the past •They already happened •Thus, they should be immutable
Examples of Domain Events UserAuthenticated Appointment Confirmed PaymentReceived $¢£¥
Designing Domain Events •Each Event is a Class •Use a common interface (e.g. IDomainEvent) •Capture when the event took place •Include details •What would you need to know to trigger this event again? •Include identitiesof any entitiesinvolved •Initialize all state in constructor •No behavior or side effects –just state
More DDD Topics •Aggregates •Repositories •Factories DDD Fundamentals on Pluralsight Eric Evans’ DDD Book steve.smith@falafel.com
Domain Models and MVC Models •UI interacts directly with Domain Model •Entities, Value Objects •Interfaces, Services •Views may work with custom ViewModels •Client (HTML/JS) code may use another ViewModelas well
Controllers •Keep as small as possible •Eliminate business logic •Inject all dependencies
Views •No logic unless encapsulated in tested helpers •No business logic if it can instead be modeled in the domain
SignalR •Awesome addition to ASP.NET •Great for notifications to multiple users •Ties in easily with Domain Events
Solution Structure •Core •Interfaces •Model (Entities, Value Objects) •Domain Services •Infrastructure •DbContext •File Access •System Clock Access •Email services •Web •MVC Project •No direct use of Infrastructure
Demo Putting DDD into ASP.NET MVC
Domain-Driven Design with ASP.NET MVC

More Related Content

Domain-Driven Design with ASP.NET MVC

  • 1. Domain-Driven Designwith ASP.NET MVC Steve Smith CTO, Falafel Software @ardalis| steve.smith@falafel.com
  • 2. What is Domain-Driven Design (DDD)?
  • 4. Communication •Ubiquitous Language •Domain Expert Interaction Modeling •Core Domain •Generic Subdomains •Bounded Context •Context Map •Shared Kernel •Anti-Corruption Layer Implementation •Model-Driven Design •Layered Architecture •Entities •Value Objects •Services •Factories •Aggregates •Repositories •Domain Events
  • 5. DDD is BIG “The more you know, the more you realize you know nothing.” Socrates
  • 6. DDD Fundamentals Course •Over 4 hours of content (demos using MVC + SignalR) •http://bit.ly/PS-DDD
  • 7. DDD Benefits •Flexibility •Software models customer’s understanding of problem •Breaks complexity into manageable pieces •Well-organized; easily tested •Business logic lives in one place
  • 8. DDD Drawbacks •Time and Effort •Learning Curve •Overkill without Complexity •“Anemic” domain model problem
  • 9. Communication “As software developers, we fail in two ways: we build the thing wrong, or we build the wrong thing.” Me
  • 12. Language “A project faces serious problems when its language is fractured.” Eric Evans
  • 13. Ubiquitous Language •Ubiquitous–adjective. Present, appearing, or found everywhere. •Synonyms: pervasive, universal •Used within a given Bounded Context •Used in code, design documents, and conversations --Everywhere
  • 14. DomainTerms Domain Experts Problem Domain Core Domain Sub-Domains
  • 15. Bounded Contexts •Provide Separation of Concerns •Limit complexity •Should be clearly boundedand separate
  • 17. Appointment Scheduling Billing Anti- Corruption Layer
  • 18. Model Driven Design Not Data-Driven
  • 19. Layered Architecture •Ports and Adapters •Hexagonal •Onion
  • 20. Organizing in a Solution
  • 21. Entities “Many objects are not fundamentally defined by their attributes, but rather by a thread of continuity and identity.” Eric Evans
  • 22. Changing Attributes Doesn’t Change Which One We’re Talking About ID:1 •Name: Steve Smith •Twitter: @ardalis •Favorite Color: Blue ID: 1 •Name: StevenSmith •Twitter: @ardalis •Favorite Color: Blue ID: 1 •Name: Steven Smith •Twitter: @ardalis •Favorite Color: Orange
  • 25. Value Objects •Defined by their attributes •Immutable •Should have no side effects •Examples: strings, addresses, currency
  • 28. Domain Services •Not a natural part of an Entity or Value Object •Interfacedefined in terms of other model elements •Should be stateless(but may have side effects)
  • 29. Services in Different Layers UI Layer & Application Layer Infrastructure Domain (“Application Core”) Message Sending Message Processing XML Parsing UI Services Transfer Between Accounts Process Order Send Email Log to a File
  • 30. Domain Events “Use a Domain Event to capture an occurrence of something that happened in the domain.” Vaughn Vernon Implementing Domain-Driven Design
  • 31. Domain Event Tips •Consider for cases of “whenthis happens, then…” •Or “Notify someone when…” •Domain events represent the past •They already happened •Thus, they should be immutable
  • 32. Examples of Domain Events UserAuthenticated Appointment Confirmed PaymentReceived $¢£¥
  • 33. Designing Domain Events •Each Event is a Class •Use a common interface (e.g. IDomainEvent) •Capture when the event took place •Include details •What would you need to know to trigger this event again? •Include identitiesof any entitiesinvolved •Initialize all state in constructor •No behavior or side effects –just state
  • 34. More DDD Topics •Aggregates •Repositories •Factories DDD Fundamentals on Pluralsight Eric Evans’ DDD Book steve.smith@falafel.com
  • 35. Domain Models and MVC Models •UI interacts directly with Domain Model •Entities, Value Objects •Interfaces, Services •Views may work with custom ViewModels •Client (HTML/JS) code may use another ViewModelas well
  • 36. Controllers •Keep as small as possible •Eliminate business logic •Inject all dependencies
  • 37. Views •No logic unless encapsulated in tested helpers •No business logic if it can instead be modeled in the domain
  • 38. SignalR •Awesome addition to ASP.NET •Great for notifications to multiple users •Ties in easily with Domain Events
  • 39. Solution Structure •Core •Interfaces •Model (Entities, Value Objects) •Domain Services •Infrastructure •DbContext •File Access •System Clock Access •Email services •Web •MVC Project •No direct use of Infrastructure
  • 40. Demo Putting DDD into ASP.NET MVC