3 ms·
> then just implement persistence layer There is two ways of thinking: 1) The database schema is the fundamental model of the business, and all application lo
by goto11 4y ago
> then just implement persistence layer
There is two ways of thinking:
1) The database schema is the fundamental model of the business, and all application logic is built on top of that.
2) The application logic is the core and the database is just a utility for persistence of data.
I'm firmly in the first camp and assume the GP is also. I believe data is more crucial and will last longer than any specific application. Thinking of the database as mere "persistence" for application logic is putting the cart before the horse.
I also believe in Fred Brooks:
> Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious.
- marcosdumay 4y agoIt's not that one of those is correct and the other wrong. The issue is that one of those can change very easily, but it's much harder for the other. Also, data definitions are entirely language based, so if you doing DDD, most of what you need to discuss with other teams gets formalized on the data model, not on the logic.
- LAC-Tech 4y agoMight I humbly suggest being flexible? I'd tend towards one as well, but a lot of real world constraints can throw that out the window.
- lightbendover 4y agoIf we’re being this binary about our philosophy, I would aim for the system interfaces being the most appropriate currency.
- discreteevent 4y agoExactly. It's interfaces all the way down with plain data being the simplest interface at the bottom. (Sometimes if a part of the domain is just about data storage and retrieval then this interface is enough)