Domain Driven Design in the Browser: Better Living through Software Modeling
•Transferir como PPTX, PDF•
3 gostaram•3,157 visualizações
hakkalabs.co
Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (9)
Semelhante a Domain Driven Design in the Browser: Better Living through Software Modeling
Semelhante a Domain Driven Design in the Browser: Better Living through Software Modeling (20)
Mais de Hakka Labs
Mais de Hakka Labs (20)
Último
Último (20)
Domain Driven Design in the Browser: Better Living through Software Modeling
- 3. Domain Driven Design in the Browser Better Living through Software Modeling
- 5. The job of software is to solve problems having to do with a particular domain.
- 6. 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.
- 11. Research EasyBib
- 12. Successful software starts with a focus on the domain.
- 13. How do I “focus on the domain?”
- 14. First, seek understanding from domain experts. They know more than you do. experts are sometimes known as “business stakeholders” or “product
- 15. Who is an expert in my domain?
- 16. Matchmaking These people (shadchanim)
- 17. Social Networking This guy.
- 18. Data Analysis George Box (a famous statistician)
- 19. Graphic Design David Carson
- 20. Research Allison “I Know a Lot About Research” Cloyd
- 21. Next, create a model of the domain that you can use in your software.
- 22. What is a model?
- 23. A blueprint of the domain that exists in the mind of the developer.
- 24. 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
- 25. Some common misconceptions about the model
- 26. 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.
- 27. 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.
- 28. 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.
- 29. Some perks of using a model
- 35. How do I translate the domain expert’s knowledge into a model?
- 36. 1.Verbal Communication 2.Diagramming 3.Use Cases
- 37. The Stuff that Models are Made Of
- 38. Entities Objects with a unique, persistent identity We track this identity using a key or a combination of properties
- 39. Some examples of entities: Entity Type Identifier • Person/User Email • Bank Account Account # • Shipping Route Id • Book ISBN
- 40. 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
- 41. Name
- 42. Factories The job of factories is to make entities
- 43. Printer
- 44. Services Services are the verbs of an application. Their state doesn’t matter so much. They have a job to do.
- 45. CitationService
- 46. 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 BookRepository.save(). 4. Using the name of the CiteStyle, pass the Book to a ViewFactory for formatting and return the View.
- 47. Repositories The persistence layer Buckets for data
- 48. 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 repository.read() 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.
- 51. 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.)
- 52. Domain Layer • Entities • Factories • Services • Repositories • Any other domain-specific logic that’s reusable across applications
- 53. 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
- 54. Some Rules for Layered Architecture
- 55. Information flows one way: up
- 56. 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.
- 57. Let’s Get Some Practice For some more good reading, go to http://www.loewenbraeuzelt.de/wp-content/ uploads/DomainDrivenDesignQuicklyOnline.pdf Or check out Eric Evans’ Book, Domain Driven Design
- 58. In This Presentation • See the working app: cornellnotes.nodejitsu.com • GraphJS: https://github.com/cameronprattedwards/graphjs • entity-context: https://github.com/cameronprattedwards/entity-context Contributors wanted!