4 ms·

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

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.

ehnto 4y ago
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.
- Jenk 4y ago
  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.
  - guywhocodes 4y ago
    This is exactly the point that I routinely see fail in organizations doing "DDD", it's closer to the absolute opposite of DDD in fact.
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 ago
  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.
- LAC-Tech 4y ago
  Might 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 ago
  If we’re being this binary about our philosophy, I would aim for the system interfaces being the most appropriate currency.
  - discreteevent 4y ago
    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)
bob1029 4y ago
> 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.

ehnto 4y ago

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.

Jenk 4y ago
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.
- guywhocodes 4y ago
  This is exactly the point that I routinely see fail in organizations doing "DDD", it's closer to the absolute opposite of DDD in fact.

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 ago
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.
LAC-Tech 4y ago
Might 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 ago
If we’re being this binary about our philosophy, I would aim for the system interfaces being the most appropriate currency.
- discreteevent 4y ago
  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)

bob1029 4y ago

> 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.