A very common practice in our industry is to first build the UI and tie in the back-end thereafter. The argument, for the most part, has been tha...
For further actions, you may consider blocking this person and/or reporting abuse
I'm totally with you on building domain use cases first.
I'd take it a step further and try to remove the technical from it. Then the order doesn't matter and can potentially be worked on in parallel.
The use cases need a user first which in most cases is a human, so it's equally important to design your UI use cases also. Software is built for humans first.
Agreed. Use cases is a bit of a loaded word so perhaps a bad choice.
My intent was that shared understanding of the goals based on user needs would need to be established before starting the formal UI or the backend. Starting without will likely be a difficult road regardless.
The Formal UI and backend knowledge would leverage mockups and wireframes that were made during the quest for shared understanding. Keeping in mind it'll likely change as the process moves forward. ;)
The fastest way I've found is to create a data and domain model while working the UI in a wireframe tool. Review wireframe with users until they see what they expect and both UI and wireframe with developers until they understand the domain. Document and use as a guide, not the absolute truth or spec as many things will change. Then break the project into smaller pieces, prioritize, and build using agile.
How do you define the limits, abstractions of the domain if you don't know what the user will want/use?
Good question. I would say that those abstractions are defined by the business rules. These rules should not know about the existence of the presentation layer nor should the presentation layer be concerned about where the data comes from.