4 ms·

My definition of DDD involves drawing up a series of relational tables in excel and reviewing those with the business stakeholders. If the product is like most

My definition of DDD involves drawing up a series of relational tables in excel and reviewing those with the business stakeholders. If the product is like most, I'd then convert those excel workbooks to SQL schemas and start building some vertical slice demos. None of this has anything to do with micro services, source control, etc. The schema (domain) is the most important part of the product. If your manager can understand it and you have a common language for communicating about it, you might actually have a viable business.

hamdouni 4y ago
It reminds me the Merise method : start from the data and relations https://en.wikipedia.org/wiki/Merise https://en.wikipedia.org/wiki/Merise
NicoJuicy 4y ago
Do you have an example of this flow somewhere? I never thought about prototyping it in excel and it sounds weird. I'm intrigued
- Throw10987 4y ago
  I have done similar prototyping in docs, whiteboards, CSV files... The flow is to focus on the data and what are the constraints(rules) on updating the data. The prototyping of api's, screens can come later off of a firm foundation of data, calculations and rules for creation and change. 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." -- Fred Brooks, The Mythical Man Month (1975)
- pfarrell 4y ago
  Not the OP, but I’ve tried this before too. A huge benefit is that the everyone at the table understands excel and isn’t intimidated during the conversation. Understanding the domain as an engineer is the toughest, most important, and most rewarding part of DDD imho.
- fudged71 4y ago
  Check out the relational data modelling capabilities in the Power Pivot Diagram view. It helps you graphically see the relations between basic excel tables.
- Yhippa 4y ago
  I actually like to screen-share or project this: https://start.jhipster.tech/jdl-studio/ https://start.jhipster.tech/jdl-studio/. You can update this real-time and see your ERD real-time.
_bax 4y ago
The same is what I did every new product. And it works. And I found not a excel aternative for this job.
tester756 4y ago
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.
torben-friis 4y ago
Good data modelling is a big part of it but it’s not keeping you from many potential problems. If you have several unrelated teams accessing and modifying the same tables, you’re guaranteed to have some headaches the moment one needs to make changes without affecting the others. So interfaces isolating those access points to data become a must, and having clear owners of those access points that can maintain the interface contract or break it in a safe and coordinated manner is a godsend. From that point on, the separation of code ownership kinda follows organically from data ownership. Microservices are absolutely not a necessity, but in non disciplined organisations they tend to help enforce code and data ownership. It’s easier to keep a team from taking shortcuts and importing a piece of code or directly accessing data they shouldn’t when it is not technically possible to do so. Does that warrant the extra complexity? Debatable.
defenestration 4y ago
Years ago, when we just founded our company, I asked an experienced CTO: 'In your experience, what is the most expensive thing to adjust later on?'. He said: 'Changes in your datamodel'. That advice worked out well. We spent extra time designing our datamodel and it saved us quite a lot of money / time on refactoring later. So making schema discussions as concrete as possible with Excel together with business stakeholders sounds like a smart thing to do.
UK-AL 4y ago
DDD is about behaviour rather than just data. In fact many business domains don't map in relational very well.

hamdouni 4y ago

It reminds me the Merise method : start from the data and relations https://en.wikipedia.org/wiki/Merise https://en.wikipedia.org/wiki/Merise

NicoJuicy 4y ago

Do you have an example of this flow somewhere? I never thought about prototyping it in excel and it sounds weird. I'm intrigued

Throw10987 4y ago
I have done similar prototyping in docs, whiteboards, CSV files... The flow is to focus on the data and what are the constraints(rules) on updating the data. The prototyping of api's, screens can come later off of a firm foundation of data, calculations and rules for creation and change. 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." -- Fred Brooks, The Mythical Man Month (1975)
pfarrell 4y ago
Not the OP, but I’ve tried this before too. A huge benefit is that the everyone at the table understands excel and isn’t intimidated during the conversation. Understanding the domain as an engineer is the toughest, most important, and most rewarding part of DDD imho.
fudged71 4y ago
Check out the relational data modelling capabilities in the Power Pivot Diagram view. It helps you graphically see the relations between basic excel tables.
Yhippa 4y ago
I actually like to screen-share or project this: https://start.jhipster.tech/jdl-studio/ https://start.jhipster.tech/jdl-studio/. You can update this real-time and see your ERD real-time.

_bax 4y ago

The same is what I did every new product. And it works. And I found not a excel aternative for this job.

tester756 4y ago

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.

torben-friis 4y ago

Good data modelling is a big part of it but it’s not keeping you from many potential problems. If you have several unrelated teams accessing and modifying the same tables, you’re guaranteed to have some headaches the moment one needs to make changes without affecting the others. So interfaces isolating those access points to data become a must, and having clear owners of those access points that can maintain the interface contract or break it in a safe and coordinated manner is a godsend. From that point on, the separation of code ownership kinda follows organically from data ownership. Microservices are absolutely not a necessity, but in non disciplined organisations they tend to help enforce code and data ownership. It’s easier to keep a team from taking shortcuts and importing a piece of code or directly accessing data they shouldn’t when it is not technically possible to do so. Does that warrant the extra complexity? Debatable.

defenestration 4y ago

Years ago, when we just founded our company, I asked an experienced CTO: 'In your experience, what is the most expensive thing to adjust later on?'. He said: 'Changes in your datamodel'. That advice worked out well. We spent extra time designing our datamodel and it saved us quite a lot of money / time on refactoring later. So making schema discussions as concrete as possible with Excel together with business stakeholders sounds like a smart thing to do.

UK-AL 4y ago

DDD is about behaviour rather than just data. In fact many business domains don't map in relational very well.