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

131–140 of 175 posts

Re: Why Domain Driven Design?

#131

Post by theptip »

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…

Why do you need to do it ahead of time? Typically what actually happens is you build a monolith, then note that one team needs to own one chunk, so you split it out into its own service.

For example from my experience, splitting an Auth/User service for security/compliance, or splitting a Payment service for the same reasons.

Or splitting out a core low-level platform layer that per-product teams can build atop, allowing each to iterate faster, while the Platform layer focuses on clean abstractions.

Nothing in DDD or microservices says you need to sit down and design the service boundaries up-front, indeed most of the advice I’ve seen in the community suggests the opposite.

Re: Why Domain Driven Design?

#132

Post by JamesBarney »

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…

Did he elaborate on how big he thought the team needed to be before microservices were required for DDD?

Re: Why Domain Driven Design?

#133

Post by gadflyinyoureye »

layer8 wrote: post #82
still_grokking wrote: post #35

Earlier quoted context omitted.

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.

Even this confuses people. Often the name of the interface is something like S3Client. No, the name should be something like PolicyWriter.

Re: Why Domain Driven Design?

#134

Post by dang »

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…

I worked on a number of software projects with Eric and got a lot out of his book before that. I'm sure you have good reasons for disliking DDD and I bet Eric would probably agree about most of them. This is what happens when ideas spread broadly. They end up getting applied in ways the originator never intended. (Jung reportedly said "thank god i'm not a jungian")

Eric's a fine writer and one of the smartest and most interesting people I've met. Nothing "snapped in his mind" and I can tell you for certain that he never tried to "force every idea into a class hierarchy" (quite the contrary! - he's very much a programming pluralist and spent a few years working in Clojure for that very reason). Nor would he ever do something as crude as trying to force a model (any model) onto software development as a whole. He's far too inquisitive and flexible a thinker.

By the way, Eric's way of programming and of thinking about programming was formed in the Smalltalk world, well before Java existed. Like a lot of the Smalltalk diaspora who ended up working in Java (and experiencing it as a kind of exile from the powerful and flexible Smalltalk environments they were used to), he thought deeply about what the differences were and how the Smalltalk design culture could be (partly) recovered and reshaped for these other technologies. A lot of creative work came out of that, not just DDD (e.g. Ward Cunningham's work, which led to Wikipedia).

Re: Why Domain Driven Design?

#135

Post by theptip »

anon7725 wrote: post #116
BulgarianIdiot wrote: post #42

Earlier quoted context omitted.

Precisely. But this is how it should be. The service is a part of the team, but automating the "mundane things" that people can delegate to machines, instead of doing them manually themselves. This is why, BTW, I'm so dismayed Elon Must fired 85% of Twitter. Now many of their critical services have teams of zero or one developer. Those are basically dead services walking.

> Precisely. But this is how it should be. The service is a part of the team, but automating the "mundane things" that people can delegate to machines, instead of doing them manually themselves. The organization is often not reflective of what’s actually being achieved. Instead of Catalog, Offer, Order and Shipment you have Alice’s org, Bob’s org and Charlie’s org. If you encode the interfaces between these (imperman…

This is true, but I think things like DDD provide an antidote (or at least, some pressure to organize along different dimensions).

If you are explicitly talking about business domains and bounded contexts, then you can see areas where the Alice/Bob split is not optimal (typically, lots of team coupling across org boundaries). Without those concepts I think it is easier to justify arbitrary political/territorial org structures.

There is no panacea; one can always provide contorted justifications for things. But I think having a framework really helps, and particularly, having one that includes business stakeholders and not just pure technical functions.

Re: Why Domain Driven Design?

#136

Post by mharig »

shinzui wrote: post #106
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.

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

Re: Why Domain Driven Design?

#137

Post by theptip »

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…

I think what you describe is a mis-application of DDD. One service per entity is way overkill and nothing like Evans would advocate for. As you note, the whole point of Aggregates is that you can select all the sub-entities in one DB transaction, which you lose across service-boundaries.

One domain service per Bounded Context is the starting point I usually see. And you can decompose into “private microservices” implementing components within a BC as needed. You might also have many “infra services/components” implementing that logical service for the BC. (For example, a service might have Django API, RabbitMQ, Postgres, Redis, Celery components. And you could split an auth microservice from the API if needed for isolation. But the external Service API remains the set of operations that make sense within a BC.)

It sounds like this company might be approaching “services per engineer” instead of measuring “engineers per service”, which is a red flag for me. There is alot of overuse of the microservice pattern as part of the hype wave.

Re: Why Domain Driven Design?

#138

Post by nightski »

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 only works if you have a blockchain to keep track of it all. ;)

Re: Why Domain Driven Design?

#139

Post by theptip »

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…

> true but is too obvious to be interesting.

I think most orgs don’t act this way, which suggests to me that it’s not actually obvious.

> However, DDD has relatively little to say about the most crucial part of that too - how to shape and define that language.

I don’t think this is actually true. (Relative to what? Other architectural systems?) It strongly advocates for a process of identifying Entities, by iteratively working worth the domain experts. The core entities should be domain objects not technical concepts. (The opposite conceptual pattern I often see is making the core objects generic functional/behavioral/logical operations with the business rules as config that’s passed through. Maybe more sensical for pure technical users, but gibberish for business users. Perhaps valid for building a generic business logic platform like SAP though!) The concept of Ubiquitous Language mandates that you have a dialog with domain experts, and keep doing that as the domain evolves. The concept of a Bounded Context gives guidance on how to judge between different potential splits in your domain, which is more than most architectural frameworks offer. All of these mean you are better placed to agree on boundaries that make sense to the business/domain as well as technical functions.

I think Aggregates and Repositories are a good low-level concepts for working with Domain-driven architectures, but they don’t participate in the higher-level organizational discourse.

Re: Why Domain Driven Design?

#140

Post by lowbloodsugar »

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…

No plan survives contact with the enemy. But without a plan, neither will you.
Post reply on HN