4 ms·

I also always start with the "database" design or the storage model or whatever you want to call it. If you do database design with proper foreign key relation

I also always start with the "database" design or the storage model or whatever you want to call it. If you do database design with proper foreign key relationships, etc, the entire rest of the design including the UI and most of the business rules can all flow directly from that. You can also do that with a good domain model but the rigors of actually having to physically construct it in a database ensures less mistakes. Now, if you're using a loosy-goosy JSON blog storage solution than there is no advantage to starting at that level.

EpicEng 8y ago
Eh... I don't know. Each approach has its advantages, but in my experience, I usually have an easier time when I start with the domain model and application logic. More often than not my initial assumptions are wrong and I have to change the model. Easier to change the code than the DB as well as the code. If I hit a weird structural issue than I can usually just rewrite that but in isolation.
- wvenable 8y ago
  I find I can tease out better assumptions and requirements by starting with the model. You immediately need answers to vital questions (more than one address, how are items related, etc). It's so valuable, I can't imagine starting any contentious project without doing that. If my assumptions are wrong, I go back the model and change that and reflow the changes back through the rest of product. It's again usually pretty easy and mechanical to make those changes once the model is again correct.
  - EpicEng 8y ago
    Yep, it can go the other way as well. I'm not religious on this one. I know what my experience has been, but those are pretty specific cases. I may change my mind next year, who knows?
bbojan 8y ago
"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.”
- mooreds 8y ago
  https://en.wikiquote.org/wiki/Fred_Brooks https://en.wikiquote.org/wiki/Fred_Brooks in case anyone wanted the source.

EpicEng 8y ago

Eh... I don't know. Each approach has its advantages, but in my experience, I usually have an easier time when I start with the domain model and application logic. More often than not my initial assumptions are wrong and I have to change the model. Easier to change the code than the DB as well as the code. If I hit a weird structural issue than I can usually just rewrite that but in isolation.

wvenable 8y ago
I find I can tease out better assumptions and requirements by starting with the model. You immediately need answers to vital questions (more than one address, how are items related, etc). It's so valuable, I can't imagine starting any contentious project without doing that. If my assumptions are wrong, I go back the model and change that and reflow the changes back through the rest of product. It's again usually pretty easy and mechanical to make those changes once the model is again correct.
- EpicEng 8y ago
  Yep, it can go the other way as well. I'm not religious on this one. I know what my experience has been, but those are pretty specific cases. I may change my mind next year, who knows?

bbojan 8y ago

"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.”

mooreds 8y ago
https://en.wikiquote.org/wiki/Fred_Brooks https://en.wikiquote.org/wiki/Fred_Brooks in case anyone wanted the source.