Mais conteúdo relacionado

Similar a Domain Driven Design in the Browser - Cameron Edwards(20)


Mais de Hakka Labs(20)


Domain Driven Design in the Browser - Cameron Edwards

  1. Domain Driven Design in the Browser Better Living through Software Modeling
  2. The job of software is to solve problems having to do with a particular domain.
  3. What’s a Domain? A domain is an area of expertise. It could be a industry field, like accounting, or a subject of interest, like penguins.
  4. Matchmaking OkCupid
  5. Social Networking Facebook
  6. Data Analysis SumAll
  7. Graphic Design Photoshop
  8. Research EasyBib
  9. Successful software starts with a focus on the domain.
  10. How do I “focus on the domain?”
  11. First, seek understanding from domain experts. They know more than you do. experts are sometimes known as “business stakeholders” or “product
  12. Who is an expert in my domain?
  13. Matchmaking These people (shadchanim)
  14. Social Networking This guy.
  15. Data Analysis George Box (a famous statistician)
  16. Graphic Design David Carson
  17. Research Allison “I Know a Lot About Research” Cloyd
  18. Next, create a model of the domain that you can use in your software.
  19. What is a model?
  20. A blueprint of the domain that exists in the mind of the developer.
  21. 0100101111010101 0010010101010101 0010100101010101 0010101010100010 0100101010101010 1000100100100000 1110101010101000 1010111011010101 1010100100100011 0100000011101010 1010100000101010 1001101001010111 0100101011010101 0101010101010101 0101000111000111 1001001100101010 1010001010101011 1011010101001010 1001010101000000 study research hypothesis control group experiment conjecture theorem law theory evidence abstract introduction premise discussion findings conclusion footnotes citations reference explanation methodology thesis support database explication essay news opinion book source review peer editor commentary empirical history case
  22. Some common misconceptions about the model
  23. The model is not source code. You have code that reflects the model, and it contains words that come from the model. But code is just an implementation of the model. The model exists in the mind of the developer.
  24. The model is not the database. Some of the data associated with the model is in the database. And the database schema is another implementation of the model. But the model encompasses all of the domain logic AND data, and it exists in the mind of the developer.
  25. The model is not a diagram A diagram is just a picture of the model. The model itself exists in the mind of the developer.
  26. Some perks of using a model
  27. Ubiquitous Language
  28. Scalably Handling Complexity
  29. Manageable Knowledge Sharing
  30. How do I translate the domain expert’s knowledge into a model?
  31. 1.Verbal Communication 2.Diagramming 3.Use Cases
  32. The Stuff that Models are Made Of
  33. Entities Objects with a unique, persistent identity We track this identity using a key or a combination of properties
  34. Some examples of entities: Entity Type Identifier • Person/User Email • Bank Account Account # • Shipping Route Id • Book ISBN
  35. Value Objects Second class objects with no identity, just value Value objects are always properties of entities They’re immutable: they’re usually only changed by replacement
  36. Name
  37. Factories The job of factories is to make entities
  38. Printer
  39. Services Services are the verbs of an application. Their state doesn’t matter so much. They have a job to do.
  40. CitationService
  41. CitationService.formatBook(string title, CiteStyle style) 1. Call the WorldCat API to get publication info about the book. 2. Pass the WorldCat response object to BookFactory.fromWorldCat() 3. For analytics, pass the Book object to BookRepository and call 4. Using the name of the CiteStyle, pass the Book to a ViewFactory for formatting and return the View.
  42. Repositories The persistence layer Buckets for data
  43. Some Benefits of Repositories • A repository is an interface, so you can read and write persistent data without knowing where it’s going. You can say and it might read from a REST API, web sockets, local storage, or even memory. • That’s why a repository is called a Persistence Abstraction Layer.
  44. Layered Architecture
  45. Application Domain Utilities
  46. Application Layer • Views • RequestControllers (traditionally called “Controllers”) • ViewModels • Assets - CSS, JavaScript, images • UI Details - UIControllers, Data Bindings • Any other application-specific logic (console applications, cron tasks, etc.)
  47. Domain Layer • Entities • Factories • Services • Repositories • Any other domain-specific logic that’s reusable across applications
  48. Utilities Layer • Libraries - Math Utilities, CSV Parsers, DOM Selection Utilities, Data Structure Helpers, ORM Tools • Frameworks - Backbone, Symfony, Rails, Django • Anything that’s reusable across domains
  49. Some Rules for Layered Architecture
  50. Information flows one way: up
  51. References Objects in one layer can refer to objects in any lower layer. Objects in one layer can refer to objects in that same layer. Objects in one layer CANNOT REFER TO OBJECTS IN A HIGHER LAYER.
  52. Let’s Get Some Practice For some more good reading, go to uploads/DomainDrivenDesignQuicklyOnline.pdf Or check out Eric Evans’ Book, Domain Driven Design
  53. In This Presentation • See the working app: • GraphJS: • entity-context: Contributors wanted!