Domain-Driven Design with ASP.NET MVC
•
24 likes•20,588 views
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.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (14)
Similar to Domain-Driven Design with ASP.NET MVC
Similar to Domain-Driven Design with ASP.NET MVC (20)
More from Steven Smith
More from Steven Smith (20)
Recently uploaded
Recently uploaded (20)
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
- 27. Immutable!
- 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