Successfully reported this slideshow.

ZendCon 2011 UnCon Domain-Driven Design

5

Share

Loading in …3
×
1 of 63
1 of 63

ZendCon 2011 UnCon Domain-Driven Design

5

Share

Download to read offline

Domain-driven design is a collaborative process involving both domain experts and software practitioners. This high-level overview takes a look at the driving principles behind domain-driven design. It also explores domain-driven design's building block patterns, supple design, strategic design, and distillation of the core.

Domain-driven design is a collaborative process involving both domain experts and software practitioners. This high-level overview takes a look at the driving principles behind domain-driven design. It also explores domain-driven design's building block patterns, supple design, strategic design, and distillation of the core.

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

ZendCon 2011 UnCon Domain-Driven Design

  1. 1. Domain-Driven Design A Collaboration Between Domain Experts and Software Practitioners
  2. 2. The Book http://domaindrivendesign.org/books/evans_2003
  3. 3. do·main dōˈmān n. a sphere of knowledge, in uence, or activity "domain." Merriam-Webster.com. 2011. http://www.merriam-webster.com/dictionary/domain (17 October 2011).
  4. 4. Core Domain
  5. 5. Core Domain • complexity is in the domain, not the technology
  6. 6. Core Domain • complexity is in the domain, not the technology • let technology play a supporting role
  7. 7. Core Domain • complexity is in the domain, not the technology • let technology play a supporting role • uncover your core domain and distill this core
  8. 8. The Model* *In domain-driven design, the model is not the classes or objects representing concepts within the model.
  9. 9. The Model* • a model is a tool for solving speci c problems within a domain *In domain-driven design, the model is not the classes or objects representing concepts within the model.
  10. 10. The Model* • a model is a tool for solving speci c problems within a domain • “the map is not the territory” —Alfred Korzybski *In domain-driven design, the model is not the classes or objects representing concepts within the model.
  11. 11. The Model* • a model is a tool for solving speci c problems within a domain • “the map is not the territory” —Alfred Korzybski • collaborative explore the model with both domain experts and software practitioners *In domain-driven design, the model is not the classes or objects representing concepts within the model.
  12. 12. Bounded Context
  13. 13. Bounded Context • there are always multiple models
  14. 14. Bounded Context • there are always multiple models • explicitly de ne a bounded context to which a model applies
  15. 15. Bounded Context • there are always multiple models • explicitly de ne a bounded context to which a model applies • speak a ubiquitous language within a bounded context
  16. 16. Building Blocks
  17. 17. Entity
  18. 18. Entity • de ned by a thread of continuity and identity
  19. 19. Entity • de ned by a thread of continuity and identity • only responsibilities should be around identity and life cycle
  20. 20. Entity • de ned by a thread of continuity and identity • only responsibilities should be around identity and life cycle • may be composed of other entities and/or value objects
  21. 21. Value Object
  22. 22. Value Object • de ned by its encapsulated attributes
  23. 23. Value Object • de ned by its encapsulated attributes • treat value objects as immutable
  24. 24. Value Object • de ned by its encapsulated attributes • treat value objects as immutable • delegate business logic to value objects
  25. 25. De ning an object as an entity or a value object is context-dependent.
  26. 26. Aggregate
  27. 27. Aggregate • a group of related entities and value objects
  28. 28. Aggregate • a group of related entities and value objects • useful when de ning transaction, distribution and concurrency boundaries
  29. 29. Aggregate • a group of related entities and value objects • useful when de ning transaction, distribution and concurrency boundaries • designate one entity as the aggregate root
  30. 30. Aggregate • a group of related entities and value objects • useful when de ning transaction, distribution and concurrency boundaries • designate one entity as the aggregate root • allow external references to only the aggregate root
  31. 31. Aggregate • a group of related entities and value objects • useful when de ning transaction, distribution and concurrency boundaries • designate one entity as the aggregate root • allow external references to only the aggregate root • delegate persistence of an aggregate root to a repository
  32. 32. Domain Event 1. http://martinfowler.com/eaaDev/EventSourcing.html
  33. 33. Domain Event • something important that happens within the domain that may lead to a state change in a domain object 1. http://martinfowler.com/eaaDev/EventSourcing.html
  34. 34. Domain Event • something important that happens within the domain that may lead to a state change in a domain object • current state can be computed by looking at all currently known domain events (a.k.a. event sourcing[1]) 1. http://martinfowler.com/eaaDev/EventSourcing.html
  35. 35. Domain Event • something important that happens within the domain that may lead to a state change in a domain object • current state can be computed by looking at all currently known domain events (a.k.a. event sourcing[1]) • domain events can trigger other domain events (e.g. three strikes triggers an out) 1. http://martinfowler.com/eaaDev/EventSourcing.html
  36. 36. Supple Design
  37. 37. Closure of Operations
  38. 38. Closure of Operations • have a method on a value object that returns an instance of the same type of value object
  39. 39. Closure of Operations • have a method on a value object that returns an instance of the same type of value object • any method arguments should also be the same type as the value object
  40. 40. Closure of Operations • have a method on a value object that returns an instance of the same type of value object • any method arguments should also be the same type as the value object • example: 2 + 3 = 5
  41. 41. Closure of Operations • have a method on a value object that returns an instance of the same type of value object • any method arguments should also be the same type as the value object • example: 2 + 3 = 5 • “2” is a value object of type number
  42. 42. Closure of Operations • have a method on a value object that returns an instance of the same type of value object • any method arguments should also be the same type as the value object • example: 2 + 3 = 5 • “2” is a value object of type number • number has an add method
  43. 43. Closure of Operations • have a method on a value object that returns an instance of the same type of value object • any method arguments should also be the same type as the value object • example: 2 + 3 = 5 • “2” is a value object of type number • number has an add method • add method accepts an argument of type number
  44. 44. Closure of Operations • have a method on a value object that returns an instance of the same type of value object • any method arguments should also be the same type as the value object • example: 2 + 3 = 5 • “2” is a value object of type number • number has an add method • add method accepts an argument of type number • add method returns a number
  45. 45. Other Techniques • intention-revealing interfaces • side-effect free functions • assertions
  46. 46. Strategic Design
  47. 47. Context Map
  48. 48. Context Map • draw a context map of the current bounded contexts
  49. 49. Context Map • draw a context map of the current bounded contexts • map what actually exists—not what you wish existed!
  50. 50. Context Map • draw a context map of the current bounded contexts • map what actually exists—not what you wish existed! • identify relationships between contexts
  51. 51. Relationship Patterns customer/ anticorruption partnership supplier layer shared kernel big ball of separate ways mud open host conformist published service language
  52. 52. Distillation
  53. 53. Multiple Models
  54. 54. Multiple Models • there are always multiple models
  55. 55. Multiple Models • there are always multiple models • a model my represent:
  56. 56. Multiple Models • there are always multiple models • a model my represent: • your core domain
  57. 57. Multiple Models • there are always multiple models • a model my represent: • your core domain • a supporting domain
  58. 58. Multiple Models • there are always multiple models • a model my represent: • your core domain • a supporting domain • a generic subdomain
  59. 59. Multiple Models • there are always multiple models • a model my represent: • your core domain • a supporting domain • a generic subdomain • focus your modeling efforts on the core domain
  60. 60. Identifying the Core Domain Ask organizational leaders and domain experts: • What keeps you awake at night? • What makes your system worth writing? • Why not buy it off the shelf? • Why not outsource it?
  61. 61. Don’t settle on not having access to a domain expert!
  62. 62. Thank You @BradleyHolt http://bradley-holt.com http://joind.in/4003 Copyright © 2011 Bradley Holt. All rights reserved.

Editor's Notes

  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Is a telephone number an entity or a value object? In a CRM, it’s probably a value object. In a telephone company, a phone number may be an entity.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • ×