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

101–110 of 175 posts

Re: Why Domain Driven Design?

#101

Post by joaodlf »

See, the thing with DDD is that it is VERY complex. I mean, "the" book on it (Evans) is beefy. Putting all those ideals in practice is hard, especially when so many of the ideas are not necessarily to do with the act of software development - No, they are social concepts, the way a team should approach the business and people outside of the tech teams.

That's why every single implementation of DDD is different. Every company that "implements" DDD does it differently. I've seen this a few times now.

Honestly, at this point, it's a bit like Agile.

Re: Why Domain Driven Design?

#102

Post by bob1029 »

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…

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

Re: Why Domain Driven Design?

#103

Post by zmgsabst »

tegiddrone wrote: post #90

I'm pretty hungry for this level of philosophy in software design, especially when I see us all too frequently just take a loose blog summary of a hot pattern and start building systems with it. I work with a company that tried to do DDD microservice patterns. It now seems clearer that the team has started to drive towards a practice of sometimes making a new microservice when a new Entity emerges from requirements w…

We did something like DDD:

- we did the ubiquitous language part, working with clients to arrive at consistent, particular language to describe the problem

- we then made a big chart of things and their relationships; get clients to sign off this describes problem

- but we didn’t bother with any formal steps passed that; we just took the chart as a systems diagram and implemented that

There’s some deep sense in which any program which encodes the chart is a type embodying the semantics of the chart, viewed as a categorical diagram. So it’s not too surprising this works out alright.

I think the ubiquitous language part of DDD is great; I’m not sure it has much to say about turning domain diagrams into software.

Re: Why Domain Driven Design?

#104

Post by mharig »

Every problem has its fitting programming paradigm, at least in the main paradigms: declarative, imperative, functional, object oriented.

DDD seems to be inevitably connected with OOP, at least I've never read something else.

Hyping one paradigm will lead to using this paradigm in an inappropriate way, sometimes or often.

(FYI: I didn't read the linked blog posting, because of medium.com)

Re: Why Domain Driven Design?

#105

Post by [deleted] »

treis wrote: post #93
BulgarianIdiot wrote: post #52

Earlier quoted context omitted.

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…

You don't need an HTTP boundary to make your own copy of data.

[deleted]

Re: Why Domain Driven Design?

#106

Post by shinzui »

mharig wrote: post #104

Every problem has its fitting programming paradigm, at least in the main paradigms: declarative, imperative, functional, object oriented. DDD seems to be inevitably connected with OOP, at least I've never read something else. Hyping one paradigm will lead to using this paradigm in an inappropriate way, sometimes or often. (FYI: I didn't read the linked blog posting, because of medium.com)

DDD offers a lot of benefits regardless of the programming paradigm. We heavily use DDD in Haskell.

Re: Why Domain Driven Design?

#107

Post by avereveard »

revskill wrote: post #2

I teach programming and software design, too. But i never use domain, driven, design,... as vocabulary. I use function all the time. "Hey guys, just use function, that's all you know to make usable software." What's the problem with NOT following "weird, confusing" patterns and vocabularies. And the result is, all of my students actually make useful code, simple code. Also, most of software recruiters will tell you:…

> Hey guys, just use function, that's all you know to make usable software

"Those who can, do, those who can't, teach" comes to mind

Re: Why Domain Driven Design?

#108

Post by discreteevent »

BulgarianIdiot wrote: post #37
goostavos wrote: post #27

Earlier quoted context omitted.

>But do you know what helps? Having physical boundaries you can't cross so easily. Rarely have I disagreed with something more strongly :) If a team lacks the discipline/skill/wherewithal to create good boundaries within a single code base when stakes are at their lowest, they absolutely don't have the skill or discipline to do ahead of time, across N code bases, and with a network in between all of them. Breaking yo…

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…

> unless physical boundaries stop you from failing

It is also possible to just police it. Supervise it. This is partly anathema now with agile etc. But the iPhone is what it is because there were a few dictators at the top saying "no". This is actually more effective than a physical boundary because:

1) People will hack around the physical boundary anyway.

2) It forces a conversation between the supervisor and the developer every time the supervisor raises an issue. At this point the developer may get a chance to learn something about the reasons for higher level structure. But more importantly the supervisor might learn something about what is wrong with the higher level structure.

Re: Why Domain Driven Design?

#109

Post by discreteevent »

lightbendover wrote: post #84
goto11 wrote: post #65

Earlier quoted context omitted.

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

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)

Re: Why Domain Driven Design?

#110

Post by c3534l »

mharig wrote: post #104

Every problem has its fitting programming paradigm, at least in the main paradigms: declarative, imperative, functional, object oriented. DDD seems to be inevitably connected with OOP, at least I've never read something else. Hyping one paradigm will lead to using this paradigm in an inappropriate way, sometimes or often. (FYI: I didn't read the linked blog posting, because of medium.com)

That's funny, I always thought of DDD as a statically typed functional programming hhing.
Post reply on HN