On 28 September 2016 at 13:00, Martin <[email protected]> wrote:
> > > In the last days have caught myself thinking about how my design of the > domain model would affect the usability of the application, especially > since I was taking into account the order in which things would have to be > done when the domain model gets more complex, just because of the fact that > one has to currently make sure certain things have to exist before others > (or as a matter of fast having to cancel a "create" action and go somewhere > else and come back, which could be frustrating too). From a purely > theoretical perspective a domain model should be free from such influences. > > What do you think? > > In general we discourage workflows... let the user navigate the domain in whichever way they wish. So your instinct is correct... just model the domain, but without worrying too much about how it is going to be rendered. I notice you talked about "pages", but that's a technical vocabulary; focus on the responsibilities underlying domain object itself. More generally, on the topic of workflows, there's a whole philosophy about this... problem solvers vs process followers, see eg [1]. The naked objects paradigm leans (quite heavily) towards the former. For high volume use cases - once the "desire lines" [2] have been discovered - then view models can be used to support those cases. For example, in Estatio [3] we generate 120 invoices at a time (one for each tenant of the shopping center). These get approved in bulk using an InvoiceSummary view model; it's responsibilities are to find all pending invoices for a property and present them to the user. We are currently in the process of extending this functionality to be able to bulk generate a (PDF) document of all invoice and then to email these documents to tenants. The way I am tackling this is to provide the capability to create a document for a single invoice, and then to email a single document. After that, the InvoiceSummary can provide the ability to do this in bulk (and to act as a "dashboard" of sorts for the users to verify that all emails have been sent). Hope that helps Dan [1] https://github.com/incodehq/radrace2015#app-requirements-actually-not-a-problem [2] https://sugoru.files.wordpress.com/2012/09/desire-line.png?w=651 [3] http://isis.apache.org/powered-by.html#_powered-by_estatio
