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

21–30 of 175 posts

Re: Why Domain Driven Design?

#21

Post by turtleyacht »

ssivark wrote: post #10
turtleyacht wrote: post #7

DDD sounds amazing, but y'all the pull requests are usually a dozen files with tiny changes. At least from what I have seen. And the promise is "change is easy" or "impact to existing code is low." This may be true. Is it? I have the Evans book. It may completely change the way I write code. But I also have "C Interfaces and Implementations," and that promises another. Yet another is Stepanov's "Elements of Programmi…

> Yet another is Stepanov's "Elements of Programming," which by first chapter's end Feynman is telling me to read it again [1]. I'm very curious what you mean by this -- is Feynman recommending Stepanov's book?

Oh--just that I couldn't understand the first chapter in Stepanov fully on first reading, so I need to read it again (and again, and again).

The Feynman reference is

  Well, I asked him, “How can I read it? 
  It’s so hard.” He said, “You start at the 
  beginning and you read as far as you can 
  get, until you are lost. Then you start at 
  the beginning again, and you keep working 
  through until you can understand the whole 
  book.”

  —Joan Feynman, Richard Feynman’s sister, 
   recalling a discussion with her brother
From https://rs.io/feynman-reading-difficult-things/

Re: Why Domain Driven Design?

#22

Post by Scarblac »

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…

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.

Re: Why Domain Driven Design?

#23

Post by turtleyacht »

alfonsodev wrote: post #15
turtleyacht wrote: post #7

DDD sounds amazing, but y'all the pull requests are usually a dozen files with tiny changes. At least from what I have seen. And the promise is "change is easy" or "impact to existing code is low." This may be true. Is it? I have the Evans book. It may completely change the way I write code. But I also have "C Interfaces and Implementations," and that promises another. Yet another is Stepanov's "Elements of Programmi…

> DDD sounds amazing, but y'all the pull requests are usually a dozen files with tiny changes. At least from what I have seen. When I've used it, a typical PR is about a Query or a Command, that calls a repository to retrieve an entity maybe performs some logic using that domain entity and stores it afterwards, three layers, application, domain and infrastructure. If you have more changes that those 3 layers (I'd say…

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 the page
     object.
From that perspective, seems the number of files changed is not bad.

I wish I had a representative example on my end. We would be able to see quickly. On the other hand, maybe there was cruft or other extras associated with just starting out with DDD with the existing conventions.

I remember there was another thing that was an issue: updating an aggregate object (?) required manually comparing each field. So the method was having to do that, spanning a page of code.

On balance, DDD affords opportunities to create maintainable code.

Do you have any experiences where the codebase was in a badly-structured form of DDD?

(Given agile development, there are good and bad ways to execute it, for example.)

Re: Why Domain Driven Design?

#24

Post by leidenfrost »

alfonsodev wrote: post #12
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…

Would you have the quote on that? I'm curious. In my opinion, Microservices is an implementation detail, and the extend to which DDD principles are applied is about people and ownership.

> Microservices is an implementation detail

It is. But it's a very strong one, where it's harder to blur the boundaries because you're putting your code into a service or another.

And that's the advantage. Not because it's easier to apply correctly. But because it's harder to do it badly.

And if you do it badly, it will show and the product performance will be a mess.

Re: Why Domain Driven Design?

#25

Post by ChrisMarshallNY »

That’s quite well-written.

For myself, I’ve learned to avoid dogma, but not let it get in the way of learning. I’ve found that I never stop learning new stuff, and realize that I’ve “been doing it wrong,” more often than I like to admit.

Frequently, I have found that “The New Way!!!” actually just formalizes or names a pattern that I’ve been using for some time.

I’ve come to learn that common sense tends to have obscure provenance.

Re: Why Domain Driven Design?

#26

Post by camgunz »

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

But if you use a framework that implements DDD (or SOA, or whatever), I'm very OK with them. For instance, I think that Django is basically DDD/CQRS/SOA: views are the service layer, models are entities, querysets are repos, REST is defacto JSON-RPC, etc. And you do start to realize the benefits: engineers aren't bogged down with irrelevant stuff like request (de)serializing, they don't have to make architecture decisions on the fly, you don't have to document/test the framework, etc. etc.

Re: Why Domain Driven Design?

#27

Post by goostavos »

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 your system apart too early, and when you know the least about it, and with the rationale that doing so will magically stop the problems that a lack of engineering skill creates, has, at least in the small slice of the world I've encountered, resulted in nightmarish levels of complexity (some of which I'm directly responsible for the reasons stated! (whoops!)).

Re: Why Domain Driven Design?

#28

Post by JamesBarney »

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

Students are never writing enough code that "what logic goes where" really matters.

But on large applications it does, and DDD is an opinionated viewpoint on how to make those decisions.

Re: Why Domain Driven Design?

#29

Post by bamboozled »

nurettin wrote: post #17

The problem with following a list of principles inside of a book is: It's hard and requires a holistic view of the entire manuscript which everyone has to remind themselves all the time. This is much more compelling: Why domain driven design? Because we have tools that detect deviations and give suggestions for expanding your models. Just like Rust constraining ownership, just like ruby on rails generating entities,…

I feel about the same about Scrum / Agile.

The theory is sound, the principal is good, in the end the execution is often lackluster.

Post reply on HN