It sounds like you started designing system from database perspective
But doesn't this "skew" your domain model in code by affecting your thoughts by technical details?
I'd prefer start with some event storming session? visualization of system and connections
then design proper domain model, correct abstractions, events between those modules inside system
then just implement persistence layer with mapper from domain model to database model which in the case of SQL contains those technical details like cache fields, FKs, etc.
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.
It'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.
Exactly. 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)
I think the OP is leaving out some of the other steps they also take. The tables give you common language for talking about the entities involved in the business logic that actually does the work.
Though I think I agree with you anyway, it is a chicken and egg problem. You can't know all things you will need schema for until you understand the businss logic requirements well, but it's hard to talk about those requirements without a common language for the entities in the business.
It is inherently flawed though, isn't it? It assumes you're in just one big schema, surely? Part of DDD is breaking that assumption and fragmenting your systems into the disparate domains withing your org, fully encapsulating your domains' functionality and data.
As someone else said, it's probably better to start with what events drive your org. What are the communication channels and triggers for those events.
> It sounds like you started designing system from database perspective
> I'd prefer start with some event storming session?
Right - We don't literally start with a blank xlsx file on day 1 of a new product or big feature.
The first conversations are about abstract outcomes, market expectations, and eventually more concrete user stories. Once we are talking about what a user experiences, we can begin to accumulate types/properties/relations.
But doesn't this "skew" your domain model in code by affecting your thoughts by technical details?
I'd prefer start with some event storming session? visualization of system and connections
then design proper domain model, correct abstractions, events between those modules inside system
then just implement persistence layer with mapper from domain model to database model which in the case of SQL contains those technical details like cache fields, FKs, etc.