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

31–40 of 175 posts

Re: Why Domain Driven Design?

#31

Post by pydry »

camgunz wrote: post #26

I think about this a lot, and I think my core beef with stuff like this is: - Engineering team has a problem - Engineer/Lead/Architect reads a book - Whole team builds an in-house, bespoke framework around the book's ideas - They now have 2 problems I'm very against in-house frameworks; I think they almost never deliver on value, and you should just use Rails/Django/etc (again, you almost certainly won't outdo them).…

It's good if those frameworks are very high quality and very thoroughly debugged like django is but if you have to spend an appreciable amount of time peeking under the hood they quickly become a nightmare.

I think about 9 out of 10 home grown frameworks end up in the nightmare bucket.

I'm super skeptical of frameworks that dont really "do" anything also. Django handles web and database and saves you from a whole load of boilerplate crap but any DDD framework would basically just be an opinionated code mold, a bit like all those dependency inversion frameworks. 100% straitjacket but with none of the boilerplate written for you.

Re: Why Domain Driven Design?

#32

Post by [deleted] »

0xCAP wrote: post #11

DDD is something not a lot of devs know about, but then every single microservices concept/pattern/architecture is basically some sort of applied DDD. Do I like the philosophy? Yes and no. Yea because it's been a great source of inspiration for me. No because I think Evans, just like Martin and a few others is basically nothing more than a businessman, trying to sell books and workshops and conferences, while being c…

[deleted]

Re: Why Domain Driven Design?

#33

Post by cies »

camgunz wrote: post #26

I think about this a lot, and I think my core beef with stuff like this is: - Engineering team has a problem - Engineer/Lead/Architect reads a book - Whole team builds an in-house, bespoke framework around the book's ideas - They now have 2 problems I'm very against in-house frameworks; I think they almost never deliver on value, and you should just use Rails/Django/etc (again, you almost certainly won't outdo them).…

> I think that Django is basically DDD/CQRS/SOA

Sure you can do DDD in Django. But I do not find that framework inherently CQRS of SOA (not SOA due to it's monolithic nature).

Maybe a monolith on BEAM (Erlang, Elixir) could be marked as SOA due to the nature of BEAMs concurrency model.

> engineers aren't bogged down with irrelevant stuff like request (de)serializing

Last Django app i saw sure had a lot of this boilerplate going. I saw this talk and thought: well this is finally a "framework" that allowes me to do away with serialization (as in: in this framework the amount of extra work you do for making the app an SPA is fairly minimal):

https://www.youtube.com/watch?v=nSrucNcwlA8&t=275s

Re: Why Domain Driven Design?

#34

Post by bob1029 »

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.

Re: Why Domain Driven Design?

#35

Post by still_grokking »

Scarblac wrote: post #22
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…

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 sounds brilliant!

What's the marketing name for that?

Re: Why Domain Driven Design?

#36

Post by goto11 »

still_grokking wrote: post #35
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 sounds brilliant! What's the marketing name for that?

"Lose coupling"

Re: Why Domain Driven Design?

#37

Post by BulgarianIdiot »

goostavos wrote: post #27
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…

>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 make a mistake.

Part of the problem is the platform itself.

Most mainstream languages today ALL support shared mutable state. Meaning you can hold a pointer or a handle to something, mutate it, and someone else having the same pointer or handle has it changed under their nose.

When you fetch, say, JSON over the network, the party who sent it to you can't change it under your nose either intentionally or accidentally. It's a snapshot of data you own, and you can make decisions on at your own leisure. Sure, the snapshot may get out of date by the time you send your next API request, but this contract is clear and obvious.

While the entangled meshes of mutable code in say C, C++, Java, Swift, Python, JS, etc. etc. often make the mess unavoidable.

Rust goes to some length to stop this problem, but it's a language that's low-level (by modern standards) and technical, and I don't think anyone uses it for enterprise automation exactly.

Another problem are nominal (vs. structural) type systems. Well I don't have to explain, but when you fetch JSON from an API a nominal type won't stop you from reading that data, you care about the structure.

Re: Why Domain Driven Design?

#38

Post by withinboredom »

still_grokking wrote: post #35
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 sounds brilliant! What's the marketing name for that?

I’ve called it Model-T development[1]. The Model-T brought standardization to building cars where companies only built to a very specific spec. It didn’t matter that some companies would be better than others, or cheaper/expensive. The point was choice, competition, and interchangeable parts. Granted, I don’t actually know about that, but that’s the end result.

[1]: I apparently deleted the post so I’ll have to undelete it and come update this comment.

Re: Why Domain Driven Design?

#39

Post by BulgarianIdiot »

marginalia_nu wrote: post #13
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…

> 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 well as it works across files, or across statements in the same file, up from data centers to CPU instructions.

Our languages and platforms are full of the SAME THING but SLIGHTLY DIFFERENT, under DIFFERENT NAMES. You listed many of them. Machine opcode, expression, function, class, module, service etc.

Re: Why Domain Driven Design?

#40

Post by vbezhenar »

camgunz wrote: post #26

I think about this a lot, and I think my core beef with stuff like this is: - Engineering team has a problem - Engineer/Lead/Architect reads a book - Whole team builds an in-house, bespoke framework around the book's ideas - They now have 2 problems I'm very against in-house frameworks; I think they almost never deliver on value, and you should just use Rails/Django/etc (again, you almost certainly won't outdo them).…

React was in-house framework.

In-house framework is fine. Just be Facebook with necessary resources.

Post reply on HN