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

81–90 of 175 posts

Re: Why Domain Driven Design?

#81

Post by blowski »

pydry wrote: post #69
radicalbyte wrote: post #59

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.

That software and organizations have boundaries and that they matter is true but is too obvious to be interesting. DDD has little to say about the most crucial aspect of those boundaries - where the boundaries go and why. There is a shared semantic model both inside a boundary and outside. However, DDD has relatively little to say about the most crucial part of that too - how to shape and define that language. DDD do…

> DDD has little to say about the most crucial aspect of those boundaries - where the boundaries go and why.

The whole point of DDD is that there can't be a one-size-fits-all answer to these questions. Instead, they give you some questions you need to think about, and tools that might help you find answers.

Re: Why Domain Driven Design?

#82

Post by layer8 »

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?

It’s called separating interface from implementation. When using an interface, only make assumptions on what the interface specifies, and not on how it may happen to be implemented. When implementing an interface, only make assumptions on what the interface specifies, and not on how it may happen to be used.

Re: Why Domain Driven Design?

#83

Post by layer8 »

turtleyacht wrote: post #21
ssivark wrote: post #10

Earlier quoted context omitted.

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

That takes quadratic time though, assuming one “gets lost” with roughly constant likelihood throughout new text. I’m sure there must be a better way.

Re: Why Domain Driven Design?

#84

Post by lightbendover »

goto11 wrote: post #65
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…

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

Re: Why Domain Driven Design?

#85

Post by d-us-vb »

What's the difference between Domain Driven Design and Problem Oriented Programming?

I feel like Chuck Moore was talking about this back in the '70s when he wrote Programming in a Problem Oriented Language. Forth has been largely overlooked probably because it lacks what people consider necessities in modern programming languages (like compiler enforced typing by default), but you can't deny the power of Forth and other concatenative languages for their ability to encode the domain.

Re: Why Domain Driven Design?

#86

Post by marcosdumay »

BulgarianIdiot wrote: post #78
marcosdumay wrote: post #72

Earlier quoted context omitted.

Modules are recursive. Libraries are recursive. Hell, functions and classes are recursive too. I don't think we have any non-recursive code abstraction tool. Some of the problem is that people need different capabilities from different abstraction layers. The rest of the problem is that there are a lot of incompetent people creating software.

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.

Re: Why Domain Driven Design?

#87

Post by za3faran »

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…

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

Java's new type offerings are immutable (records, with value and primitive types in the works). Hopefully a push in the right direction.

Re: Why Domain Driven Design?

#88

Post by lakomen »

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…

So, in short structure is half the code, is what I always say

Re: Why Domain Driven Design?

#89

Post by mannykannot »

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.

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.

Re: Why Domain Driven Design?

#90

Post by tegiddrone »

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 with no evaluation of whether it is an "Aggregate Root" or other potential analysis.

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.

Post reply on HN