Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Domain Driven Design?

yehohanan7.medium.com

Post reply on HN
Print view View original

51–60 of 175 posts

Re: Why Domain Driven Design?

#51

Post by torben-friis »

bob1029 wrote: post #34

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 un…

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.

Re: Why Domain Driven Design?

#52

Post by BulgarianIdiot »

hcarvalhoalves wrote: post #45
BulgarianIdiot wrote: post #37

Earlier quoted context omitted.

You can disagree with it and blame the developers, but the fact is that DDD fails basically every time, unless physical boundaries stop you from failing. It's like saying a good driver won't have an accident on a sharp corner of an icy road, but yet you have a ton of accidents on that corner on an icy road. Facts are facts. Just as it's a fact you can't hope every organization to be staffed by 100% geniuses who never…

Microservices alone don’t solve the shared mutable state problem, and make it even worse w/ network and eventual consistency.

They solve the mutable shared state problem that I'm specifically talking about. Which is that it's clear which state you own, and which state you don't own.

"Shared" implies shared ownership, this is where the confusion comes from. When you ask an API about a user's profile, it's that API's user profile. But the API response itself is entirely yours. It won't change right under your fingertips. The original profile may change, but you know that the profile is not yours already.

Re: Why Domain Driven Design?

#54

Post by ehnto »

tester756 wrote: post #50
bob1029 wrote: post #34

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 un…

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…

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.

Re: Why Domain Driven Design?

#55

Post by Throw10987 »

youerbt wrote: post #18

I'm divided on DDD. On one hand there are some good ideas (system is model, language is important etc) that seems "obvious", but I guess still worth explicit mention. On the other hand there are implementation techniques that strike me as not really Domain Driven, but I Program In Java With Hibernate Driven (Entities, Value Objects & Aggregates section). I wonder why those two are married other than historical accide…

I think there is general acceptance that the implementation details in Eric Evans book could almost be completly skipped. The concepts of domain boundaries and the ubiquitous language are the useful if seemingly obvious bits.

Re: Why Domain Driven Design?

#56

Post by Jenk »

ehnto wrote: post #54
tester756 wrote: post #50

Earlier quoted context omitted.

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…

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 require…

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.

Re: Why Domain Driven Design?

#57

Post by Jenk »

est wrote: post #14
BulgarianIdiot wrote: post #5

I thought the DDD hype has died down a bit, but I guess not. Eric Evans (inventor of DDD) has said in recent years that unfortunately once a team is big enough, all the invisible conceptual boundaries between domains blur and disappear. People do NOT have the discipline to do DDD correctly. But do you know what helps? Having physical boundaries you can't cross so easily. Microservices. Or as I call them... just "serv…

> once a team is big enough, all the invisible conceptual boundaries between domains blur and disappear Conway's law: Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

"Microservices" are not just an acknowledgement of this law, they are a full blown exploitation of it. They are (supposed to be?) literal implementations of your organisation's boundaries/domains.

Re: Why Domain Driven Design?

#58

Post by turtleyacht »

pydry wrote: post #44
turtleyacht wrote: post #23

Earlier quoted context omitted.

That sounds reasonable. Maybe the story included some extra things. Comparatively, it's a regular occurrence to add at least three files for a Cucumber BDD test: 1. The .feature file and one or more scenarios. 2. Adding one or more step defs to one (or more!) step def files. 3. Adding a new page object file or new methods to an existing page object. 4. Possibly, add them to a component file and *then* call that from…

>Comparatively, it's a regular occurrence to add at least three files for a Cucumber BDD test This is partly why I so dislike Cucumber. The gherkin language is insufficiently expressive for most purposes and the syntax for parameterization is just...bad. Thats how gherkin stories end up being a glorified label - it's not an intrinsic BDD problem.

It can be difficult to wrangle Gherkin. I've tried to use "Writing Great Specifications" as a kind of guide. Reducing specs to (mostly) one each of Given, When, and Then seems to reduce UI steps.

Having agnostic specs is nice if the team moves from web app to, say, React Native: should still be the same feature set.

The con is QA looking for step-by-step test instructions have to look elsewhere (at the "code"). And, I still haven't seen a real example of QA, PM, and dev working together to write Gherkin :)

Tooling can help for some warts. Gherkin is line-oriented, so a parser is easier to write. Using ex or ed, one can generate a clickable webpage of specs to kick off a test.

Interestingly, the book above recommends DDD as a way to organize test specs. One suggested exercise is to highlight words from a spec and label them as one domain or another, and determine the core domain versus secondary ones.

Of course, one chapter or a few cannot describe DDD, but interesting to see that decomposition.

Other than Cucumber, what do you use for BDD?

Re: Why Domain Driven Design?

#59

Post by radicalbyte »

The value in DDD is in the boundaries. It makes them explicit not just at technical but also organisational level.

Then within a boundary you have a shared semantic model which is explicitly documented so visitors from other domains can "speak the language".

So far none of that touches code - but Conway's Law generally results in a set of services at the boundary.

Re: Why Domain Driven Design?

#60

Post by defenestration »

bob1029 wrote: post #34

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 un…

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.

Post reply on HN