Hacker News Reader

Comment by bob1029 | Hacker News Reader

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.

View on HN

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.

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.

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.

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

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.

If we’re being this binary about our philosophy, I would aim for the system interfaces being the most appropriate currency.

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)

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.

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.

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.

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

It reminds me the Merise method : start from the data and relations

https://en.wikipedia.org/wiki/Merise

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

Do you have an example of this flow somewhere?

I never thought about prototyping it in excel and it sounds weird.

I'm intrigued

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)

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.

I actually like to screen-share or project this: https://start.jhipster.tech/jdl-studio/. You can update this real-time and see your ERD real-time.

Check out the relational data modelling capabilities in the Power Pivot Diagram view. It helps you graphically see the relations between basic excel tables.

The same is what I did every new product. And it works.

And I found not a excel aternative for this job.

Reply on news.ycombinator.com