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

151–160 of 175 posts

Re: Why Domain Driven Design?

#151

Post by thebricksta »

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…

I have a similar take to yours.

Early in my career, I really bought the stuff the Agile founding fathers promoted (Martin, Uncle Bob, Beck, etc). I tried bringing it into my code and pushing it on my teams, but it never went well. I tried finding great examples they've implemented to use as, well, examples - but never found anything. Turns out, these gurus of coding almost never release any open source code to be scrutinized outside of toy examples in their books.

I've realized the reality is that many of their suggestions are actually pretty reasonable, but they take time to implement. Most business software is written under a relative time crunch, and the time required to slow down and properly implement them is excessive and unaffordable.

More specifically, in the case of DDD, most businesses cannot afford to make every developer a domain expert so they can properly refactor to the DDD guidelines. The required think time and one-on-one time with an expert to learn the domain would be far too costly.

Further, it pushes a different type of complexity into the implementation that a non-expert cannot understand, which actually slows down future development when new hires fumble the domain. Thus, new hires end up having a longer ramp up time with less productivity and more handholding during it.

Re: Why Domain Driven Design?

#152

Post by tegiddrone »

theptip wrote: post #137
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” impl…

> which you lose across service-boundaries.

I suspect this gets resolved at this company by composing on the UI a ton. The UI can reach in and get Orders from the Orders microservice, then reach out to the LineItem microservice. Before this post, I've argued at it the other way: "A LineItem will always require an Order in context therefore maybe LineItem should be part of the Order service instead of it's own thing."

Since this isn't the first time I've seen this heavy UI composition in my career, I suppose it's time to coin and describe this DDD antipattern :)

Yeah that "engineers per service" equation seems alarming. I think we're essentially at a 1:1 ratio at a glance ; not evaluating whether there are "private microservices."

Re: Why Domain Driven Design?

#153

Post by cutemonster »

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

>> Otherwise [without microcompanies] you just can't do software engineering right.

So true

Re: Why Domain Driven Design?

#154

Post by cutemonster »

nuancebydefault wrote: post #143
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.

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.

Re: Why Domain Driven Design?

#155

Post by andrei_says_ »

ademarre wrote: post #150
doctor_eval wrote: post #149

I only read the first third of the DDD book, the conceptual parts, which I thought were excellent, especially concepts like ubiquitous vocabulary and domain boundaries, which put a name to practices we’d already discovered. But the underlying problem is that engineers are learning the domain as they write the code. This leads them to make invalid assumptions, which can go very deep, and make it extremely difficult to…

Speaking of billing, are there any good resources or examples for an engineer who gets thrown into this domain?

If I get thrown in the domain I’d probably pay for a few hours of consulting from an expert, like doctor_eval.

I’ve found nothing more efficient than a one on one conversation with a domain expert who can help me build my own mental model.

Re: Why Domain Driven Design?

#156

Post by moystard »

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.

Interested in having the quote as well, and ideally the presentation/keynote/interview that came with it.

From my experience, breaking down a monolith without first identifying and isolating its bounded contexts (as in DDD) is a recipe for disaster. With your domains completely entangled in a single codebase, you won't pull only what you want and you will have to bring a lot of undesired code, behaviours and side effects with it.

The safest recipe, in my opinion, is to break down your monolith in bounded contexts (or ideally, to have focused on it from the start), so you can better reason and understand the advantages and trade-offs of moving each specific domain and responsibilities out of your unique codebase.

I saw often teams being motivated in moving their code out of a legacy codebase because of the huge technical debt, but they were bound to suffer a death of a thousand cuts by just bring the same debt in a new service, and adding network constraints on top.

Re: Why Domain Driven Design?

#157

Post by dzikimarian »

In my experience biggest problem with DDD is that many developers are just not interested in business problem they are designing. They want blanket approach, that will allow to quickly get over design phase and get to "fun" technical problems.

DDD requires you to understand problem, find pieces that work together (have to be saved in single transaction or world burns). More importantly find pieces that doesn't have to be saved together and nothing bad happens (which is harder because it's so nice that we can setup foreign keys for everything and have always consistent data. Too bad that it isn't and doesn't need to be consistent in real world).

There's lots of opinions in these comments I heard over the years working with DDD from inexperienced developers.

* DDD equals microservices - completely wrong - you will make mistakes while dividing domain. You should start form modular monolith.

* DDD should start from relational database model - nope. You will lock yourself in unnecessary relations.

* DDD requires big pull requests for trivial changes and that's a problem - first of all, most time is spent reading code, not writing. 2 minutes more for better readibility is worth it, even if you don't like it. Secondly - it's mostly for trivial changes like a new field. Logical changes that are really hard to grasp usually are contained in a few domain classes.

* No team is able to maintain separation between domains - many teams are not able to maintain ANY architecture at all and we end up with mess anyway(often because architecture didn't care about businesses requirements and then developers complain that "bad business made them to make bad choices"). Doesn't mean we shouldn't try.

In my experience DDD done correctly is only solution that reduces cognitive load while developing big systems. However if you prefer to live by "two weeks of development will save you two hours of planning", then you aren't going to like it :-)

Re: Why Domain Driven Design?

#158

Post by kingdomcome50 »

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 prescribes or enforces any particular code organizational or deployment strategy. Easy to get wrong I suppose, and doesn't necessarily invalidate what could become a coherent argument...

But the author then has to go on and give examples of just how little they understand the topic at hand!

The first points to database software as "an example of good architectural design where their purpose of storing data is not confused with the domain the database will be used for". Oh the irony! Of course that's the case! The domain of database software is... (drumroll) persisting data! What would you expect to see if you opened the source code for an RDBMS? Code for blasting out marketing emails? I could go a step further and opine that it isn't possible to know whether any piece of software follows DDD without actually seeing the design/code base... but I digress. This point is not forgivable. It's a clear and obvious misunderstanding of DDD and how it is applied to systems.

The next examples they give are of applications they worked on! In both cases the author completely misses the fact that the software they "fixed" by decoupling it from the "domain" are simply examples where they followed DDD to create a "better" system. That's right! If the goal of your software is to create a generic "data integration application" or "workflow engine", then yes, coupling your design to "healthcare" is a mistake. Both are examples where the author is confused about what domain their software is servicing, and how aligning the software design to the correct domain was a major improvement. Hmm... sounds like DDD to me :)

I think there are valid criticisms of DDD, but the article linked is quite poor at articulating them.

Re: Why Domain Driven Design?

#159

Post by BulgarianIdiot »

treis wrote: post #93
BulgarianIdiot wrote: post #52

Earlier quoted context omitted.

They solve the mutable shared state problem that I'm specifically talking about. Which is that it's clear which state you own, and which state you don't own. "Shared" implies shared ownership, this is where the confusion comes from. When you ask an API about a user's profile, it's that API's user profile. But the API response itself is entirely yours. It won't change right under your fingertips. The original profile…

You don't need an HTTP boundary to make your own copy of data.

Do you religiously deep-clone every container you pass to a function? No. So it's one thing to say you can copy your data, another to know your data is guaranteed to be copied.

Swift has value types which use pass-by-value semantics. Containers use copy-on-write. This is a language where you can quickly build value trees that you know are a guaranteed copy, isolated from whoever sent you this tree.

But most languages have no such infrastructure. Java is adding record types, but they're immutable instead of in-place mutable, which is incredibly inconvenient to work with in nested data structures.

Re: Why Domain Driven Design?

#160

Post by doctor_eval »

ademarre wrote: post #150
doctor_eval wrote: post #149

I only read the first third of the DDD book, the conceptual parts, which I thought were excellent, especially concepts like ubiquitous vocabulary and domain boundaries, which put a name to practices we’d already discovered. But the underlying problem is that engineers are learning the domain as they write the code. This leads them to make invalid assumptions, which can go very deep, and make it extremely difficult to…

Speaking of billing, are there any good resources or examples for an engineer who gets thrown into this domain?

I don’t know, I didn’t find any. I started (20+ years ago) by talking to my accountant, but they tend to overcomplexify things.

I am thinking about doing some open source work in the space. I wonder if anyone would find it helpful. And I’m always up for consulting work :)

Post reply on HN