refactor business logic into its own layer

[yakticus]

Examples of business logic that exists between the DAO and the API layer:

• bookmark status workflow (transitions between statuses). Note: coupling between status and submitted on date should remain in the DAO
• shuffling between date formats presented/consumed in the API and the underlying DB fields
• code in ResponseFormatter

This list will invariably grow, at which point separation of concerns will become more important.

[yakticus]

See PR #13 for some banter.

Joanna: I hear you on the business-logic layer, and agree that the BookmarkStatus class, which verifies the implicit state model of the status values, does not really belong with the DAO. If that were pulled out, I would want to keep the coupling between the submitted_on date and the status in the DAO, to keep the consistency check as close to the persisted data as possible. If the BookmarkStatus would be the only class to move, I'm not sure it's worth creating another module yet, but I could go either way. My expectation would be that the API and the new business logic module could both depend on the DAO; the business logic module could not depend on the API, and the DAO module could not depend on either of the others. Is that how you are thinking about it?

Julie: I am thinking that the dependency would be API -> business logic -> DAO. I'm imagining that when doing updates, API is calling business object to get DAO-ready objects (e.g., Bookmark, BookmarkTopic), and then calls the DAO to persist stuff. Going the other direction, the API would query the DAO, then ask the business logic to turn the results into something that can be serialized to JSON. In short, the DAO would not depend on API or business logic; the business logic would not depend on the API; the API could depend on both DAO and business logic.