Mais conteúdo relacionado

Similar a Domain-Driven Design(20)


Domain-Driven Design

  1. Domain-Driven Design A Collaboration Between Domain Experts and Software Practitioners
  2. The Book
  3. Training
  4. do·main dōˈmān n. a sphere of knowledge, influence, or activity "domain." 2011. (17 October 2011).
  5. Complexity is in the domain, not the technology
  6. Case Study: Election Reporting
  7. Elections vs. Referendums Elections and referendums are not as similar as they at first appear Election winners may be determined by plurality and/or winning threshold Referendums can only be passed by meeting a winning threshold
  8. Local vs. Statewide Elections Town Meeting Day (March) elections are very different than statewide elections (November) During statewide elections, voters may be voting in both local and statewide elections at the same time—each with different district boundaries District boundaries dictate reporting needs—statewide elections need to be reported one way, local elections another
  9. Districts Some districts may contain only part of a municipality or ward The Chittenden-3-6 Vermont Representative District contains all of Winooski and part of Burlington’s Ward 1 Citizens in this part of Burlington’s Ward 1 vote in Winooski for statewide elections and in Burlington for local elections Audience expects both aggregate and detailed reporting Redistricting can occur between elections
  10. Let technology play a supporting role
  11. Models are tools used to solve domain problems
  12. Ames Room Used in The Lord Of The Rings: The Fellowship of the Ring to make the hobbits appear the correct size in relation to Gandalf We are always using mental models to understand the world around us—we do not perceive an objective reality By Alex Valavanis (own work) [public domain], via Wikimedia Commons
  13. "Why I prefer Fahrenheit to Celsius [Fixed]." reddit. 2012. (16 September 2012).
  14. Collaboratively explore the model with both domain experts and software practitioners
  15. Case Study: Three-Dimensional Animation
  16. Software Practioner: Edwin Catmull Studied physics and computer science Made many notable computer graphics discoveries Eventually moved from two-dimensional to three-dimensional animation Hired by Lucasfilm to bring his expertise to the entertainment field
  17. Domain Expert: John Lasseter Studied animation and taught by veteran animators from Disney Realized early-on the potential for computer generated imagery Worked at, but eventually fired from, Disney Hired by Edwin Catmull at Lucasfilm as an “Interface Designer” because Catmull’s job didn’t include hiring animators[1] 1. Buckley, A. M. "Chapter 3: Art Meets Science." Pixar: The Company and Its Founders. Edina, MN: ABDO, 2011. 27. Print.
  18. “Throughout the process, Lasseter worked side-by-side with the computer scientists. Lasseter’s requests pushed them to develop new tools, and their feedback helped him learn the digital animation process.”[1] 1. Buckley, A. M. "Chapter 3: Art Meets Science." Pixar: The Company and Its Founders. Edina, MN: ABDO, 2011. 30. Print.
  19. Identify your core domain
  20. Core Domain Identify your core domain Distill your core domain Focus your resources on the core domain
  21. Collaboratively explore domain models
  22. The Model A model is an abstract set of tools that is used to solve problems within a domain While represented in code, do not think of the model as just code A “real world model” is a fool’s errand The model must be explored collaboratively with domain experts and software practitioners
  23. “The map is not the territory.” —Alfred Korzybski
  24. Magritte, René. The Treachery of Images (La trahision des images). 1929. Oil on canvas. Los Angeles County Museum of Art, Los Angeles, California.
  25. This is not a pipe. Magritte, René. The Treachery of Images (La trahision des images). 1929. Oil on canvas. Los Angeles County Museum of Art, Los Angeles, California.
  26. "Everything simple is false. Everything which is complex is unusable." —Paul Valéry
  27. There are always multiple models
  28. Bounded Context Delineates the applicability of a particular model Bounded contexts allow each model to be explored in isolation Clearly define: • Who is responsible for each bounded context • To which parts of the application is the bounded context applicable • What manifestations the bounded context will take (code, database schemas, etc.) Document the interactions between bounded contexts with a context map
  29. Ubiquitous Language Speak a ubiquitous language within a bounded context Terms must be clearly defined, unambiguous, and consistent Critically important when communicating between domain experts and software practitioners The ubiquitous language will (and must) evolve as a progressively richer understanding of the domain and the model are achieved If the ubiquitous language cannot be used to clearly express complex ideas, then you have more work to do!
  30. Exploring the Model
  31. A Model Exploration Process Ask a domain expert to tell you a story (the scenario) Propose a model Code the scenario using unit tests Repeat
  32. Use concrete scenarios in discussions with domain experts and in unit tests
  33. Building Blocks
  34. Entity Defined 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
  35. Value Object Defined by its encapsulated attributes Treat value objects as immutable Delegate business logic to value objects
  36. Defining an object as an entity or a value object is context-dependent
  37. Aggregate A group of related entities and value objects Useful when defining transaction, distribution and concurrency boundaries A model will likely have multiple aggregates
  38. Aggregate Root Designate one entity as the aggregate root Allow external references to only the aggregate root Use unidirectional references within an aggregate root for less complexity • Example: Reference a line item’s order, or an order’s line items, but not both Maintain references on the “many” side of a “one-to-many” relationships for less complexity: • Example: Reference a line item’s order, rather than an order’s line items
  39. Repository Delegate persistence of an aggregate root to a repository A repository should behave as if it were an in-memory data store If using an object-relational mapper (ORM): Database -> ORM -> Repository Use an in-memory strategy for unit tests Straddles persistence and domain layers, allowing you to stay focused on the domain model
  40. Service A place for operations that aren’t naturally part of any domain object Like value objects, services should be immutable Operations on services are stateless
  41. Command-Query Responsibility Segregation (CQRS)
  42. Commands & Queries Commands are responsible for changing state Queries are responsible for retrieving state A commands may delegate the actual state change to a domain event
  43. Write Model/Read Model Define one model for writing data (commands) Define another model for reading data (queries) Both models will likely share aggregate root entity identifiers
  44. Event Sourcing[1] 1.
  45. Domain Event Something important that happens within the domain that may lead to a state change in a domain object Domain events can trigger other domain events (e.g. three strikes triggers an out) Domain events are immutable Typically stored in an event log
  46. Event Log Current state can be computed by reading the event log Retroactive events can be used to “fix” application state Current state may be cached, if necessary for performance Can also serve as an audit log
  47. Supple Design
  48. 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 integer • integer has an add method • add method accepts an argument of type integer • add method returns an integer • integers are closed under the operation of addition
  49. Other Techniques Intention-revealing interfaces Side-effect free functions Assertions
  50. Strategic Design
  51. Context Map Draw a context map of the current bounded contexts Map what actually exists—not what you wish existed! Identify relationships between contexts
  52. Relationship Patterns customer/ anticorruption partnership supplier layer shared kernel big ball of separate ways mud open host conformist published service language
  53. Distillation
  54. Types of Domains A model my represent: • your core domain • a supporting domain • a generic subdomain Focus your modeling efforts on the core domain Consider outsourcing work on supporting domains Consider off-the-shelf software for generic subdomains
  55. 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?
  56. Don’t settle on not having access to a domain expert!
  58. Thank You @BradleyHolt Copyright © 2011-2012 Bradley Holt. All rights reserved.

Notas do Editor

  1. \n
  2. \n
  3. \n
  4. \n
  5. \n
  6. \n
  7. \n
  8. \n
  9. \n
  10. \n
  11. \n
  12. \n
  13. \n
  14. \n
  15. \n
  16. \n
  17. \n
  18. \n
  19. \n
  20. \n
  21. \n
  22. \n
  23. \n
  24. \n
  25. \n
  26. \n
  27. \n
  28. \n
  29. \n
  30. \n
  31. \n
  32. \n
  33. \n
  34. \n
  35. \n
  36. \n
  37. 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
  38. \n
  39. \n
  40. \n
  41. \n
  42. \n
  43. \n
  44. \n
  45. \n
  46. \n
  47. \n
  48. \n
  49. Dates are another example of where closure of operations could be useful\n
  50. \n
  51. \n
  52. \n
  53. \n
  54. \n
  55. \n
  56. \n
  57. \n
  58. \n
  59. \n