Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Introducing domain driven design - dogfood con 2018

538 views

Published on

DDD provides a set of patterns and practices for tackling complex business problems with software models. Learn the basics of DDD in this session, including several principles and patterns you can start using immediately even if your project hasn't otherwise embraced DDD. Examples will primarily use C#/.NET.

Published in: Software
  • Be the first to comment

Introducing domain driven design - dogfood con 2018

  1. 1. No Content Here (Reserved for Watermark) Introducing Domain- Driven Design (DDD) @ardalis Ardalis.com Steve Smith
  2. 2. No Content Here (Reserved for Watermark) Tweet Away! • Live Tweeting and Photos are encouraged • Questions and Feedback are welcome • Use #DDDesign • Mention @ardalis
  3. 3. No Content Here (Reserved for Watermark) Online Training See me after for: • 1-month free Pluralsight pass • 20% off any DevIQ course
  4. 4. No Content Here (Reserved for Watermark) https://ardalis.com/architecture-ebook http://microsoft.com/net/learn/architecture Sample: https://github.com/dotnet-architecture/eShopOnWeb Covers ASP.NET Core 2.1 monolithic app development along with several DDD principles and patterns. Free Microsoft eBook
  5. 5. No Content Here (Reserved for Watermark) Weekly Dev Tips WeeklyDevTips.com 5-10 minute long episodes Focus on tips, tools, gotchas, patterns Prefer email? ardalis.com/tips newsletter Grab a sticker!
  6. 6. Starting down the path…
  7. 7. No Content Here (Reserved for Watermark) What is Domain-Driven Design? Focus on the problem domain Not the database, or even the code implementation Tools for better communication and knowledge discovery Patterns for modeling solutions Without tight coupling to infrastructure concerns
  8. 8. No Content Here (Reserved for Watermark) Some new thing? Domain-Driven Design published in 2004
  9. 9. No Content Here (Reserved for Watermark) Why You Should Care about DDD History of success with complex projects Principles & patterns to solve difficult problems Clear, testable code that represents the domain Aligns with practices from experts’ experience
  10. 10. No Content Here (Reserved for Watermark) Flexible Customer’s vision/perspective of the problem Path through a very complex problem Well-organized and easily tested code Business logic lives in one place. Many great patterns to leverage Benefits of Domain Driven Design
  11. 11. No Content Here (Reserved for Watermark) While Domain-Driven Design provides many technical benefits, such as maintainability, it should be applied only to complex domains where the model and the linguistic processes provide clear benefits in the communication of complex information, and in the formulation of a common understanding of the domain. —Eric Evans Domain-Driven Design
  12. 12. No Content Here (Reserved for Watermark) Time and Effort Learning curve (why you’re here) Only makes sense when there is complexity in the problem Team or Company Buy-In to DDD Drawbacks of DDD
  13. 13. No Content Here (Reserved for Watermark) DDD Concepts
  14. 14. No Content Here (Reserved for Watermark) The Domain
  15. 15. No Content Here (Reserved for Watermark) Core Domain Your company (or product/division)’s primary space in which they solve customers’ problems Key differentiator Problem Domain The overall domain of the specific problem your application will address / solve Generic Subdomains Separate applications or features your application must interact with. Not necessarily core to your app. What are “domains”
  16. 16. No Content Here (Reserved for Watermark) Domains refer to problem spaces. Domain Models and Bounded Contexts are parts of a solution.
  17. 17. No Content Here (Reserved for Watermark) Bounded Contexts Domain-Driven Design
  18. 18. No Content Here (Reserved for Watermark) Appointment Scheduling Bounded Context Billing
  19. 19. No Content Here (Reserved for Watermark) Explicitly define the context within which a model applies… Keep the model strictly consistent within these bounds, but don’t be distracted or confused by issues outside. —Eric Evans
  20. 20. No Content Here (Reserved for Watermark) Bounded Context Appointment Scheduling Billing
  21. 21. No Content Here (Reserved for Watermark) What’s important to one bounded context may not be (as) important in another.
  22. 22. No Content Here (Reserved for Watermark)
  23. 23. No Content Here (Reserved for Watermark)
  24. 24. No Content Here (Reserved for Watermark) Relates to the Solution you are building The domain represents the problem your solution is solving Core Domain – the business’s primary focus/industry Sub-Domain – a particular area within a larger domain. Maps to a software solution and bounded context. Bounded Context
  25. 25. No Content Here (Reserved for Watermark) Context Maps Client Patient Appointment Notification Exam Room Client Procedure Invoice Notification One DB To Rule Them All Appointment Scheduler Billing vet-managr The Dev Team
  26. 26. No Content Here (Reserved for Watermark) Context Maps Client Patient Appointment Notification Exam Room Client Procedure Invoice Notification Appointment Scheduler Billing DB DBAuthentication User Shared Kernel vet-appt-sched Team Awesome vet-billing Team Ultimate
  27. 27. No Content Here (Reserved for Watermark) Ubiquitous Language http://upload.wikimedia.org/wikipedia/commons/2/23/Rosetta_Stone.JPG
  28. 28. No Content Here (Reserved for Watermark) A project faces serious problems when its language is fractured. —Eric Evans
  29. 29. No Content Here (Reserved for Watermark) Ubiquitous Language For a single Bounded Context Used throughout that context, from conversations to code Bounded Contexts should also have names, to aid in disambiguation.
  30. 30. No Content Here (Reserved for Watermark) The Domain Model Domain-Driven Design
  31. 31. No Content Here (Reserved for Watermark)
  32. 32. The Domain Model
  33. 33. No Content Here (Reserved for Watermark) BehaviorsSchedule an appointment for a checkup Note a pet’s weight Request lab work Notify pet owner of vaccinations due Accept a new patient Book a room Not AttributesAppointment.Time Pet.Name Owner.Telephone Room.Number FOCUS ON
  34. 34. No Content Here (Reserved for Watermark) Rich Domain ModelsAnemic Domain Models
  35. 35. No Content Here (Reserved for Watermark) “The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters.” —Martin Fowler http://martinfowler.com/bliki/AnemicDomainModel.html
  36. 36. No Content Here (Reserved for Watermark) Push behavior into the model objects (entities, value objects) Tell the stateful model objects what operation to perform Don’t Ask them for their state, operate on them, and then update their state Only resort to services when you can’t put logic with its state Access dependencies via domain events Tell, Don’t Ask
  37. 37. No Content Here (Reserved for Watermark) Many objects are not fundamentally defined by their attributes, but rather by a thread of continuity and identity. —Eric Evans Domain-Driven Design
  38. 38. No Content Here (Reserved for Watermark) Entities Have Identity & Are Mutable Jan 12 10:00 am Check-Up Snickerdoodle Appointment ID=358 & Vaccinations ID=172 XXXX 9:30 am
  39. 39. No Content Here (Reserved for Watermark) ENTITIES Entities in the Navigation Map Evans, Domain-Driven Design, p. 65
  40. 40. No Content Here (Reserved for Watermark) Entities should minimize direct access to their state (e.g. public property setters) Encapsulate changes by exposing well-defined methods Entities should be responsible for their own behavior Be especially wary of collection properties! EF Core 1.1+ supports encapsulation of properties (exposing IEnumerable or ReadOnlyCollection) Encapsulation
  41. 41. No Content Here (Reserved for Watermark) Dependencies and Entities Don’t inject dependencies into entity constructors And of course don’t new up or call static infrastructure dependencies This often leads to moving interesting behavior out of entities and into services Consider raising domain events Behavior requiring dependencies shifts to domain event handlers
  42. 42. No Content Here (Reserved for Watermark) VALUE OBJECTS
  43. 43. No Content Here (Reserved for Watermark) Value Object Measures, quantifies, or describes a thing in the domain. Identity is based on composition of values Immutable Compared using all values No side effects
  44. 44. No Content Here (Reserved for Watermark) Value Object Example Company Worth: $50,000,000 $ 50,000,000 Worth (Value Object) Monetary Unit (string) “U.S. Dollar” Amount (decimal): 50000000 Company (Entity) ID (guid): 9F63CE8D-9F1E-45E0-85AB-C098CC15F8E6 Worth Unit (string): “US Dollar” Worth Amount (decimal): 50000000 Company (Entity) ID (guid): 9F63CE8D-9F1E-45E0-85AB-C098CC15F8E6 Worth { Source:http://fit.c2.com/wiki.cgi?WholeValue (Ward Cunningham)
  45. 45. No Content Here (Reserved for Watermark) DateTimeRange public class DateTimeRange { public DateTimeRange(DateTime start, DateTime end) { Start=start; End=end; } public DateTime Start { get; private set; } public DateTime End { get; private set; } … } Patient Appointment 10:00 am Jan 4, 2014 – 11:00 am Jan 4, 2014 Staff Meeting 2:00 pm Feb 1, 2014 – 3:15 pm Feb 1, 2014
  46. 46. No Content Here (Reserved for Watermark) It may surprise you to learn that we should strive to model using Value Objects instead of Entities wherever possible. Even when a domain concept must be modeled as an Entity, the Entity’s design should be biased toward serving as a value container rather than a child Entity container. —Vaughn Vernon Implementing Domain Driven Design
  47. 47. Patterns
  48. 48. No Content Here (Reserved for Watermark) Aggregates
  49. 49. No Content Here (Reserved for Watermark) Aggregates
  50. 50. No Content Here (Reserved for Watermark) Aggregates Customer Address Customer Aggregate Product Component Product Aggregate 1 N N 1 Aggregate Root Aggregate Root
  51. 51. No Content Here (Reserved for Watermark) Aggregates Product Component Product Aggregate N 1
  52. 52. No Content Here (Reserved for Watermark) An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes. —Eric Evans Domain-Driven Design
  53. 53. No Content Here (Reserved for Watermark) Important operations that don’t belong to a particular Entity or Value Object Good Domain Services: Not a natural part of an Entity or Value Object Have an interface defined in terms of other domain model elements Are stateless (but may have side effects) Live in the Core of the application Domain Services Result Value Object Entity 2 Entity 1 Service
  54. 54. No Content Here (Reserved for Watermark) Examples of Services in Different Layers UI Layer & Application Layer InfrastructureDomain (“Application Core”) Message Sending Message Processing XML Parsing UI Services Transfer Between Accounts Process Order Send Email Log to a File
  55. 55. No Content Here (Reserved for Watermark) Repository Palaeoclimate archives: Core repository of AWI Hannes Grobe/AWI Creative Commons Attribution 3.0
  56. 56. No Content Here (Reserved for Watermark) A repository represents all objects of a certain type as a conceptual set…like a collection with more elaborate querying capability. —Eric Evans Domain-Driven Design
  57. 57. No Content Here (Reserved for Watermark) Repository Benefits Provides common abstraction for persistence Promotes Separation of Concerns Communicates Design Decisions Enables Testability Improved Maintainability
  58. 58. No Content Here (Reserved for Watermark) Client code can be ignorant of repository implementation …but developers cannot N+1 Query Errors Inappropriate use of eager or lazy loading Fetching more data than required Common Repository Blunders
  59. 59. No Content Here (Reserved for Watermark) Enforce proper Aggregate usage by only creating Repositories for Aggregates Use Marker Interfaces to identity Aggregate Roots Constrain generic repository implementations to work with Aggregate Root types only Repositories and Aggregates
  60. 60. No Content Here (Reserved for Watermark) Avoid returning IQueryable results Initially, use separate methods for specialized queries and commands Address method explosion, SRP violation, and too much Repository complexity with the Specification pattern Repository Method Tips
  61. 61. No Content Here (Reserved for Watermark) Domain Events (one of my favorites) Specification Learn more about these from my Pluralsight courses: • DDD Fundamentals • Design Patterns Library - Specification More Patterns (we don’t have time for)
  62. 62. No Content Here (Reserved for Watermark) Or tweet me @ardalis and I’ll answer later. Let me know if I can help your team get up to speed with DDD, Clean Architecture, and/or .NET Core. Questions?
  63. 63. No Content Here (Reserved for Watermark) No Content Here (Reserved for Watermark) No Content Here (Reserved for Course Previews) Thanks! Follow us: /DevIQPage DevIQ.com/updates @deviq • full-length courses • samples • member-only events Enroll in DevIQ for access to: DevIQ.com/enroll Ardalis.com @ardalis | steve@deviq.com Steve Smith

×