Which Comes First - The Object Model or the Screens?
On the whole we typically design web apps by starting with a collection of business intents. We then work to identify the smallest set of essential tasks (essential use cases) to achieve those business intents. From there we describe the screens (view), actions (controller) and steps (model method calls) required to implement those use cases (including optional and exceptional paths).
For simpler web applications we find that you can actually infer the object model directly from the screens on the basis that if you don't need to display, order by, filter by, export or report on a given property of an object then the property doesn't need to exist. Equally, unless you need to administrate, display, export or report on information that depends on a relationship, you don't need to include that relationship in the model. So it doesn't MATTER whether an article is associated to a practice area unless in the application you're going to display a list of articles for each practice area or report on the number of articles per practice area.
For many sub-$25k apps this actually works quite well and I could see an interface that would allow a developer to simply describe the screens in sufficient detail using a collection of formal Domain Specific Languages that would completely generate the model purely by inference from the screens (where screens have to include API responses, log data, imports, exports and reports as well as the more common lists, details and forms to fully capture the required model). However, as the applications get richer, I often find that more decisions need to be made about the design of the model (does an order have composed billing and shipping addresses or just contain the fields for those addresses?) which can't be optimized without a little bit of thought.
On the other hand, I think that in most cases a "model first" approach is not always the most efficient approach. While it is always interesting to understand the domain model well (I love Eric Evans work on Domain Driven Design), you run the risk of modeling relationships or information about the domain that isn't needed to facilitate the application you're building. For example, I find that a lot of novice designers often fall into the trap of trying to completely model all of the relationships in a domain rather than asking themselves which of those relationships actually relate to the app they need to build.
How do you design your web apps? How do you balance use cases and domain modeling? Any thoughts appreciated!
(Or did I miss the point?)
On the whole though, I'd definitely say the use cases are more important than the modeling. The client should mostly care less what the model looks like, and you can (structurally) design something quite beautiful - but who cares if it doesn't meet the needs of the client?
@Brian, I tend to agree - that's the way I'm finding works best, although I'm still trying to figure out how and where true object model "design" fits into the process.
Like you both, I'll start by trying to determine business intent from the client, and if some particular workflow needs to be implemtented, that as well. Now, I haven't started a web/site/ from scratch in quite a while, so this might only be pertinent to backend web/apps/.
Based on that initial meeting, I can normally have a (mostly) fully functioning app up very quickly (or module if the app is made up of several of them). It might not look pretty, but it works more than well enough to get useful feedback. If I've got a lot of work to do, I'll try to meet at least weekly with them. If not, I can go as quick as several times a day.
Generally, I don't need to share single pieces of data between screens - it would be a reusable "view" function that gets put in other places. If I delete a property, also it doesn't normally hurt me because I try not to do anything without being dynamic about it. However, for those edge cases where it does hurt, I just have to remember to change it (or run my selenium tests to find out if anything breaks, assuming I have them) (or do a find in files for it and check each individually). If I do have to remember to change it (which I should point out has yet to happen since I got into all this dynamic stuff and doing the above), I imagine I would have kept it in one reusable place so that I could just change it to output nothing instead of breaking.
Now, I would absolutely love to make a tool or find one that would help me in those refactorings - to let me know that if I remove propertyX, Y places will be affected, and they are I, J, K...Z But to be honest, I just haven't run into that trouble yet.
What I was getting at in my previous comment (that it doesn't matter because they're only minutes apart) was that I could care less about them, because changes to one place cascade to another (in a good way) the way I try to do it. I try to have so little custom code (and that which is custom is isolated) that I don't need to worry about it much. I admit that the fact I've yet to run into the problem is partially luck of the draw, but I think I've created at least some of that luck.
I'd probably make it where they describe the screen first - like drag a form control onto the page - then name that form control... Have you used Visual Studio's Windows Forms drag and drop features? I think that worked decent.
Basically I'd keep it iterative - they don't describe ALL the screens and then ALL the object model - instead, they describe part of a screen, part of the model behind it, and so forth. Then they can reference other object models from other screens.
At least when I was thinking about it, that's what I was going to do. Funny enough, I was talking to a developer in the same office as me this morning about that. That's the only reason I figured out what you're asking.
I guess we've all heard of FLiP? http://www.fusebox.org/go/learning-fusebox/flip