video: https://www.youtube.com/watch?v=WpkDN78P884
- 7:00 structure of a typicaly rails app
- top level dir structure communicates that it is a rails app, not what the app actually does
- the web is just a delivery mechanism, just a detail, yet it dominates your project structure
- floorplan of a library, church, etc
- the top-level structure of these buildings conveys their intent / purpose
- why are we reflecting the web framework rather than the intent of the app?
- 12:20 Object-Oriented Software Engineering: A Use Case Driven Approach by Ivar Jacobson
- he talks about how to get the intent of the app expressed at the top-level structure
- user story vs use-case
- 15:20 Jacobson's model:
- "interactor" object: represents a use-case
- for application-specific business rules
- "entities"
- for application-non-specific business rules (orders, customers, etc)
- interactors and entities are decoupled from database and delivery mechanism (web)
- "boundaries" (interfaces, protocols)
- how to get data into / out of interactors and entities
- note direction of dependencies, delivery mechanism can be replaced / pluggable
- request model, result model: not web-specific
- tests can be written without involving the web/server at all
- project would be structured around boundaries, interactors and entities
- structure of project thus reflects the intent of the application
- interactors are e.g. "create order", "add item to order", "deliver order", etc
- "interactor" object: represents a use-case
- 29:00 MVC
- invented by Trygve Mikkjel Heyerdahl Reenskaug, in smalltalk
- controller gets input from user, view presents data to user, view observes model
- originally, every part of the view hierarchy had its own controller and model
- these days we have diverged (e.g. iOS: typically one controller per screen)
- flaw: both controllers and views know about the business objects
- rant about the web
- 35:20 "presenter" translates a result model into (e.g. a web-specific) view model
- "view" is simple, "dumb" mapping from view model to output format
- tests for views are less important
- "view" is simple, "dumb" mapping from view model to output format
- note: the arrows seem to indicate "this piece knows about (is coupled to) this piece", rather than data flow
- everything to the left of the line can be created as a library
- which can be used by any particular delivery mechanism
- everything to the left of the line can be created as a library
- 39:00 digression about tests
- 40:25 Database
- database should not be the center of the application, it is just a detail
- "entity gateway"
- "architecture is the art of drawing lines (boundaries) with the rule that all the dependencies (arrows) which cross that line go in the same direction"
- e.g. not ok for objects on both sides of the line to "know about" (be coupled to) each other
- database is isolated as a plugin, and it not needed when e.g. running tests
- tests with no delivery mechanism and no database can be run very quickly
- note: active record, ruby, etc are on the other side of the line from the business logic
- 46:00 digression about "fitnesse" application (a testing framework and wiki)
- deferred decision about choosing a database, ended up not needing it at all (just used flat files)
- digression about ward cunningham's accomplishments
- "a good architecture allows major decisions to be deferred"
- e.g. rails is just a detail, database is just a detail
- "a good architecture maximizes the number of decisions not made"
- e.g. keeps your options open for as long as possible
- 58:00 digression about TDD
