38 ms·
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 busines
by 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 agoIt 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 agoThis is exactly the point that I routinely see fail in organizations doing "DDD", it's closer to the absolute opposite of DDD in fact.