The author advocates starting with database design before software. Some other people advocate the opposite: the database is just a detail.
I think the point is to spend time in designing a good domain model regardless of how it's stored (database).
I think the point is to spend time in designing a good domain model regardless of how it's stored (database).
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.
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.
If the database is just a detail then you most likely are working on a small toy project. Or a class project. If it is a significant project where performance, scale and security matter, then database is the central concern. You have to start and end with the database. But dealing with data can be boring and cumbersome so we tend to jump to coding and proscrastinate on database and data design.
Also see: https://8thlight.com/blog/uncle-bob/2012/05/15/NODB.html
> Databases and frameworks are details!
I cringed on this part, as perhaps an all-too-common software QA scenario:
> It came down to trying to create a fake customer, with a fake order, with a fake item, with a fake item category, with a "paid" invoice, with exceptions sprinkled throughout the codebase to handle all of these special cases and probably more that I no longer remember.
You can do it iteratively, but simply inverting the order is a recipe for a mess of spaghetti that nobody will be able to touch in a just a couple of months.
One, as you mentioned, the database schema seems to be driving the functionality, not the other way around.
Two, the application is a monolith in the worst way possible. Marketing and order entry are two completely different domains. Pigeonholing then into one means you don’t exactly capture the requirements of either domain correctly.
The discussion is a good one to have, but it needs to happen at a level above where it currently is.
I believe Ulises is talking about two stages: Top-down a prototype to shake out bad assumptions, then bottom-up main development for a solid foundation.