I start the UI doscussions on a whiteboard and only move them into code after the vocabulary is understood. It sounds like we work similarly, actually.

Too bad. Agreement is not typically as fun as arguing

I am also finding more value in mocking up the UI, just pictures, no code, before hand. It gives the customer some degree of assurance. Which promptly get trashed when the real world UI constraints get thrown in.

But after that, you have a bunch of pretty pictures and no code, no tables. Do you start creating the UI, just attached to nothing?

I still think it makes sense to start with the domain at that point. You need to have your naming scheme down, and I use that to help drive the UI. But in case you missed that last part…I’m only creating the parts of the domain that I need right then…for the UI that I’m going to be working on. Agile development is still the name of the game.

I fervently agree that starting with the data tier is flat wrong. I recently told a tem at work that if they bring an ERD to a sprint review I will take in into the parking lot and burn it. As an example

On the other side, I find trememdous value in building mockups (not working code at all, just some pictures) of the User’s Experience in an application and a domain vocabulary at the same time.

I would propose that this makes more sense than starting with a middle tier, becuase your customer rarely thinks in those terms. If I am designing a system for end users, the UI is their world. Let them live in it and let them force the build of the common vocabulary in that paradigm.

Typical users (and this may not mean client) do not know about the middle tier. This means that we need to be aware of our biz layer as we work though that UI with the client. When they come up with a potential screen that you can see conflicting in that biz layer, work it out with them before you get to code.

So, in a nutshell, mockups and vocabulary first. Iterate on the mockups and vocabulary with the client before you write a line of code.

Then thin slice the application as you build it out a feature and a screen at a time, including the domain. Evolve the domain as the features actually come online.

Most often we start by designing/creating the database, then doing the “administration” side which is basically CRUD for that schema. Once done, we move on to the front end, or the “interesting part”.

I have become frustrated with this monolithic approach. The admin portion resembles how *we*, the developers, think about the data, not how the client does.

It also ensures that the client hates the admin portion unless they don’t know any better.

The entire enterprise comes down to a single question: are you making this problem easier on yourself, the developer, or on the user? Any UI based on direct CRUD operations is definitely the former.

When you start “in the middle”, i.e. a domain sans UI or storage, you get a “pure” view of the problem: no contorting it to meet the needs of a particular application layer.

This allows you to project your domain to UI or storage as needed. It also allows you to define your nouns and verbs without regard for their connotations in a particular layer.

Point being, when you start with the UI, you code your problem for the UI; when you start with the DB, your code your problem for the DB; when you start with the domain, you code your problem for the solution.