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

161–170 of 175 posts

Re: Why Domain Driven Design?

#161

Post by mavelikara »

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…

> Using the examples in this article, they might have made a "LineItem" microservice along with their "Order" microservice. This seems obviously awkward when thinking about doing this for something more commonly understood like "Order" but in our more niche domain model it isn't as obvious. So that's great to have some language/categories to point out that "LineItem" is not a an "Aggregate Root" and thus it is a indicator that it may not need to have it's own bounded-context/microservice. "Order" is an "Aggregate Root" and so it is a stronger candidate for it's own bounded-context/microservice.

EJB 1.0 specification made all entity beans remote. This lead to every interaction with every entity in the system cross a process boundary, the way you describe here. This was soon recognized to be an anti-pattern. Soon, a pattern called "Session Facade" was identified - the remote interfaces are coarse-grained operations, working on aggregate roots.

Microservice-per-entity is EJB 1.0 all over again.

Re: Why Domain Driven Design?

#162

Post by BulgarianIdiot »

marcosdumay wrote: post #86
BulgarianIdiot wrote: post #78

Earlier quoted context omitted.

If you start listing what different capabilities you need on each layer, you'll notice it can all be done, as a very lean abstraction, in one layer. I'm working on creating a platform that's doing just that, BTW. I'll cite Erlang as an example that comes somewhat close to what I mean. An Erlang process is a function, a class, a module, and a remote service, all at once. It can be done. We just never stopped to truly…

> We just never stopped to truly think about it and try. Oh, you are right about this. But a lot of people stopped to think about it. It always seemed to fail due to market failures, like most other innovations in development.

Yes, the network effects of pre-existing platforms are big. But we should keep trying I think. I think such a platform should also be inclusive enough hat it can act as a glue layer for and INSIDE existing platforms, but have richer semantics than say JSON, Protobuff or similar protocols offer.

Re: Why Domain Driven Design?

#163

Post by bamboozled »

marcosdumay wrote: post #80
bamboozled wrote: post #29

Earlier quoted context omitted.

I feel about the same about Scrum / Agile. The theory is sound, the principal is good, in the end the execution is often lackluster.

I disagree. The principal of Scrum is already rotten. Nothing in it leads to productive developers, only to micromanaged feature factories.

That's a more direct way of saying what I already think :)

Re: Why Domain Driven Design?

#164

Post by omadden »

mharig wrote: post #136
shinzui wrote: post #106

Earlier quoted context omitted.

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

Can you provide some (online) resources on DDD + functional?

Scott Wlaschin wrote a good book on this topic “Domain modelling made functional” and you can find his talks and articles online. I think this is a decent introduction, https://techleadjournal.dev/episodes/79/

Re: Why Domain Driven Design?

#165

Post by qazxcvbnm »

BulgarianIdiot wrote: post #39
marginalia_nu wrote: post #13

Earlier quoted context omitted.

> But do you know what helps? Having physical boundaries you can't cross so easily. Microservices. Or as I call them... just "services". Eric Evans has said that people using microservices may represent the most successful application of DDD's principles, not because people using them were fans or even aware of DDD, but microservices enforce the patterns DDD Evans was describing. Sir, your assembly code is so hard to…

Exactly. We need RECURSIVE DIVISION of compute/state entities. Our main mistake is that we invent a level of division, and never make it recursive, i.e. a class is badly designed to be an entire module, it can't contain classes (inner Java classes are not what I'm talking about), nor can classes cross machine boundaries easily in many languages and so on. We need a unit of division that works across machines just as…

What's the correct level of division?

Re: Why Domain Driven Design?

#166

Post by Scarblac »

mannykannot wrote: post #89
Scarblac wrote: post #22

Earlier quoted context omitted.

It's as I've always said, every function ("unit") should be responsible for a single thing, and it must be developed by an independent company with no knowledge of the other companies involved. Otherwise you just can't do software engineering right.

For that to work, there has to be, somewhere, a clear understanding of how the units all work together to achieve the higher-level goals without violating the higher-level constraints which, in practice, increase in number and scope the higher up the pyramid of abstraction you go. Pace Robert Martin, divide-and-conquer cannot be used to reduce systems-level thinking to doing just one thing, even in an abstract sense.

> For that to work, there has to be, somewhere, a clear understanding of how the units all work together to achieve the higher-level goals without violating the higher-level constraints which, in practice, increase in number and scope the higher up the pyramid of abstraction you go.

Oh, that's an implementation detail. The market will sort it out.

Re: Why Domain Driven Design?

#167

Post by Scarblac »

nightski wrote: post #138
Scarblac wrote: post #22

Earlier quoted context omitted.

It's as I've always said, every function ("unit") should be responsible for a single thing, and it must be developed by an independent company with no knowledge of the other companies involved. Otherwise you just can't do software engineering right.

This only works if you have a blockchain to keep track of it all. ;)

I'm not decided on that. On the one hand, sure, blockchain should be involved! But the single thing per company requirement would mean that the company could do nothing else but a blockchain with nothing on it.

But it does sound enticingly pure, a conglomerate of blockchain companies without further function.

Re: Why Domain Driven Design?

#168

Post by Scarblac »

cutemonster wrote: post #154
nuancebydefault wrote: post #143

Earlier quoted context omitted.

I believe that never works in practice. The thing that binds units together is also code. Only while designing / implementing that code, you encounter the flaws in the interfaces of those units, and conclude that half of the units need to be replaced or their specifications need change.

Sure, that's how things used to be. But this approach, Microcompanies as it is called (units developed by independent companies), is also partly no-code, in that the specifications and different functional units are glued together using lawyers.

> in that the specifications and different functional units are glued together using lawyers.

Exactly! And it all runs on the invisible hand of the free market.

Re: Why Domain Driven Design?

#169

Post by mharig »

omadden wrote: post #164
mharig wrote: post #136

Earlier quoted context omitted.

Can you provide some (online) resources on DDD + functional?

Scott Wlaschin wrote a good book on this topic “Domain modelling made functional” and you can find his talks and articles online. I think this is a decent introduction, https://techleadjournal.dev/episodes/79/

Thanks a lot!

Re: Why Domain Driven Design?

#170

Post by stevebmark »

kingdomcome50 wrote: post #158
stevebmark wrote: post #111

Domain Driven Design is a poison. The book is one of the most poorly written technical books out there. There are a handful of good ideas buried in the 1,000 page unedited verbose rambling slog. The whole book should only have been 10 pages. Besides Eric Evan’s inability to write, the poison of DDD comes from locking in businesses/domain concepts into your core technology, making them inflexible and making it difficu…

The following is not an endorsement of DDD. There are many glaring issues with the ideas presented in that linked "take down" of DDD. I can forgive the early strawman comparing "spreadsheets" to bespoke software solutions. As if they cover exactly equal problem/solution spaces. Fine. I'll play along... I can even forgive failing to understand that DDD is a design methodology, not an architecture; That DDD in no way p…

This confirms my suspicion that "domain" has no definition. If "storing data" is a domain than anything can be a domain, and the word is meaningless.

There are logical groupings of nouns and functionality into services / modules / orthogonal parts of the software. Aggregate root is one useful term here, domain is not.

And for me it further reinforces the point of the article: design functional horizontal layers, not ones locked into your business "domains".

Post reply on HN