Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Domain-Driven Design

verraes.net

Post reply on HN
Print view View original

151–160 of 198 posts

Re: Domain-Driven Design

#151

Post by jen20 »

oscarcp wrote: post #17

We use DDD at the current company I work in and to be honest, I detest it so much that sometimes it makes me wonder if I even want to continue in the programming space (been at it for 20 years). Don't get me wrong, DDD has meaning and purpose, but some companies are applying it as a badge to be obtained instead of pondering the question, do you really need to rewrite everything following DDD? In our case, simple CRUD…

I’ll bite: your team may say they are doing “domain driven design” but given from the description that they are not, you could just as well claim to be training alligators and be as correct.

However, you _are_ correct to say that DDD has a very limited use - as does the domain model pattern itself. Martin Fowler even calls this out in Patterns of Enterprise Application Architecture, imploring that it is necessary only when there are “complex and ever-changing business rules”. Most business systems should be multi-player Access databases, and instead have “a few sums and not-null checks”, thus should not use a domain model, thus should not use a technique aimed at designing and validating a domain model.

Honestly, I’d find a new job.

Re: Domain-Driven Design

#152

Post by afarrell »

necovek wrote: post #116
ToJans wrote: post #65

Earlier quoted context omitted.

I have a few ideas, in fact I gave a talk about that a long time ago [0], but I think one of my friends Marijn gave a good suggestion on twitter [1]: don't sell DDD, but fix your the problem your boss has. [0] https://www.slideshare.net/TomJanssens1/selling-ddd [1] https://twitter.com/huizendveld/status/1440683623628230665

I think the question was more how to sell not-doing-DDD. Reasonable people (including DDD advocates) clearly understand that tactical patterns can easily be misapplied, and that the strategic part of it is more important, but inexperienced programmers jump in on the "new" fad (it's not even that new, which is most perplexing to me), and misapply all the patterns they possibly can. I see there's a lot of similar senti…

One cause of misapplying tactical patterns is learning. When people start learning something, they do it badly and in inappropriate contexts. The solutions to this are:

A. Don't learn things.

B. Dedicate some amount of time to learn something in a sandbox before using it on the job.

C. Once you've learned something well enough to see the error of your ways, dedicate some amount of time to clean up your old work.

Re: Domain-Driven Design

#153

Post by pydry »

rewma wrote: post #96
mathiasverraes wrote: post #72

Earlier quoted context omitted.

I'm sorry you're having that experience. DDD is specifically aimed at tackling complexity, as it says on the cover. Part of the problem is that complexity is relative to the observer, how experienced they are in that particular domain, etc. Good abstractions make complexity manageable, bad ones create more complexity. And that's another problem: a domain might be quite straightforward but bad explanations, missing in…

> I'm sorry you're having that experience. DDD is specifically aimed at tackling complexity, as it says on the cover. Part of the problem is that complexity is relative to the observer, how experienced they are in that particular domain, etc. I'd say part of the problem is that DDD critics conflate DDD with overly complex, enterprisey models that don't match their personal preferences on the acceptable tradeoffs betw…

>I'd say part of the problem is that DDD critics conflate DDD with overly complex, enterprisey models

Every text I've ever written on DDD has made it pretty clear that these patterns are at the very heart of what it is. I've never seen one that says "look, all this stuff is optional, write your software however, here's how to really get to grips with the domain model".

I don't think it's the critics conflating. It is what it is.

Re: Domain-Driven Design

#154

Post by jcelerier »

oscarcp wrote: post #17

We use DDD at the current company I work in and to be honest, I detest it so much that sometimes it makes me wonder if I even want to continue in the programming space (been at it for 20 years). Don't get me wrong, DDD has meaning and purpose, but some companies are applying it as a badge to be obtained instead of pondering the question, do you really need to rewrite everything following DDD? In our case, simple CRUD…

> Don't get me wrong, DDD has meaning and purpose, but some companies are applying it as a badge to be obtained

That's the issue. If they weren't doing with DDD they would be doing the exact same thing with whatever the CEO read in Gartner instead anyways.

Re: Domain-Driven Design

#155

Post by amw-zero »

pydry wrote: post #27
oscarcp wrote: post #17

We use DDD at the current company I work in and to be honest, I detest it so much that sometimes it makes me wonder if I even want to continue in the programming space (been at it for 20 years). Don't get me wrong, DDD has meaning and purpose, but some companies are applying it as a badge to be obtained instead of pondering the question, do you really need to rewrite everything following DDD? In our case, simple CRUD…

I noticed something similar. A minimal PR to introduce DDD on our code base ballooned the codebase by something like 1,000 lines, smattered all over the code base. I think it would have ballooned it by about 12-15,000 in total in the end if we'd used it everywhere. That would have been fertile breeding ground for bugs. The ideas made sense on logically complex code that required frequent refactoring, but the strict s…

If there were a way to produce bounded context boundaries by following a general pattern / algorithm, what would that be? I fail to see how they can be created usefully without lot's of conversations with domain experts plus elbow grease. It's the part of software that remains entirely art and not science.

Why is that a bad thing?

Re: Domain-Driven Design

#156

Post by amw-zero »

pydry wrote: post #68
dm3 wrote: post #41

Earlier quoted context omitted.

> We also couldnt agree on where the limits of the bounded contexts really lay. Most documentation on this issue is a mere handwave saying "you figure it out" or "it'll become clear when you do these exercises with the business" (it didnt), which is odd given how vitally important it is and how damaging it is to bound the wrong things. This is the hardest part of software design. No wonder there are no clear cut rule…

Yeah, it is tricky. I've rewritten many a code base because I drew the original boundaries in the wrong place and their logical locations only became clear in retrospect. I'm not so convinced that it's something you can get just by better communicating with "the business" either. This is partly what infuriated me so about the extreme amount of code required to follow DDD patterns - 3-4x the amount of code means 3-4x…

That's not how lines of code work - more lines can be more clear and easier to write. There are extremely concise mathematical proofs that require extreme amount of time to produce, whereas a more verbose proof takes a simpler approach but one that involves less thinking.

Same with programs.

Re: Domain-Driven Design

#157

Post by pydry »

ratww wrote: post #134
pydry wrote: post #95

Earlier quoted context omitted.

>Doesn't matter if your code has a type named `Aggregate` in it. Matters if you get your consistency boundaries right I tended to find a lot written about the former and very little written about the latter. In fact I found essentially zero practical or actionable advice about getting the boundaries right beyond just "it's important to get it right". DDD doesnt appear to have a coherent opinion beyond that. Not in th…

I've found that separating around "abstraction levels", to use Clean Code lingo, really helps for defining good boundaries. This is really super-emphasised in Clean Code, but I find this the most important concept in the book. Examples: Are you writing to disk? Printing to the screen? Saving to the database? This is a different "abstraction level" than your data processing, those things should be separated by a bound…

>However, the part that is not really discussed on these books is that we should be vigilant not to "over-abstract".

To be fair, I've never really seen any process/paradigm address this. I've mostly done it based upon gut feel - sometimes abstractions seem like too much of an imposition. Other times it feels critical.

DDD just says "do way too much. all the time".

I imagine one day there will be an abstraction calculus but software engineering aint there yet.

Re: Domain-Driven Design

#158

Post by emteycz »

elondaits wrote: post #135
eurasiantiger wrote: post #104

Earlier quoted context omitted.

All you need is a common vocabulary around English proper nouns and some idea of how they work together. And then the client data has all fields named in Spanish with abbreviations, lettering and numbering everywhere.

I'm an Argentine Spanish-English bilingual programmer. I try to program exclusively in English, but when developing integrations to Argentine systems I often have to fall back to spanglish code. In general it's preferable to use only english because the code is more readable (because the language's keywords and APIs are in english), but also to maintain consistency with noun-adjective order, verb tenses, etc. Some lo…

I generally treat all country-specific stuff as data.

Re: Domain-Driven Design

#159

Post by sovietmudkipz »

I am working really hard on how to apply DDD to a video game context, specifically with unity3d. It is a struggle because I think the game creator cultural zeitgeist doesn’t like applying software patterns from ‘outside’ influences, like enterprise software. It is my personal view that the zeitgeist is terribly short sighted and is actually only considering the game client at the expense of the entire software system. (It is also a struggle for me because the video game community appears littered with SEO grifters, and the real experts are very secretive (so different from open source on the web). That is okay because it is fun to synthesize DDD techniques into a new context.

I think of game software as the entire system and not just the game client. That means any backend or infrastructure is a piece of the complex whole.

DDD for backend systems is well understood. The difference is it needs to serve game clients as well as any other clients (e.g. a website to market the game, forums for game related posting, maybe even run logic for chatbot(s)). If you want to expose online services to your game client, the backend system is where you will want to think about what logic to run and what state to persist.

I like DDD for some categories of game client code, not all. There are some simple gameplay elements that are driven from game engine physics and collisions. There are more complex gameplay elements that benefit from more complex domain modeling techniques. Basically allow yourself to write untested/lightly tests components for simple gameplay elements. For complex systems, it may be beneficial to think of unity as concrete implementations for domain specific logic. Model the code in the language of the game system expert and think about how to translate unity runtime events (user input, collisions) into terms meaningful for the domain.

In practical terms, unity game objects represent domain entities and interactions between game objects can trigger domain logic. For example, a projectile game object colliding with a combatant game object is a good place to execute combat service logic, which may trigger domain events (observable behavior) that can then be listened for by subscribers (e.g. a damage UI, a toast notification, or any other unity UI).

This is turning into more of a brain dump but I wanted to send this out into the world since it’s a topic I’m studying heavily right now.

Does anyone have more experience applying DDD to video games out there?

Re: Domain-Driven Design

#160

Post by amw-zero »

tinco wrote: post #11

So this is a very fundamental explanation of DDD, the kind you might learn at university. But the last time I researched DDD there was a very concrete architecture associated with it, and I didn't really understand why. Every DDD article would also introduce CQRS for some reason, it seems they are inextricably connected, at least for web application development. Anyone got a good story on that?

I'm not advocating for CQRS or any of that, I've personally never used it on a project. But, the reason that architectures are associated with DDD is that DDD is fundamentally a philosophy or an idea. Certain software designs achieve that philosophical ideal better than others.

For example, DDD stresses the idea of an "isolated domain model" - and that has a very practical reason, being that your business rules are already complicated enough so mixing in database transactions, HTTP caching, response serialization, authorization, etc. etc., into your domain logic makes it harder to understand. You want to be able to have a conversation with a customer / domain expert where they explain something and you can adjust the code quickly to meet their needs. That's the ideal goal at least.

So some patterns enable that goal better. For example, this implies that you need some kind of data access layer pattern so that code that cares about the database is separate from code that cares about domain logic. Well, there's a million different ways to get that separation, and they have different tradeoffs, and like everything else, certain patterns become trendy. That's what's going on with CQRS. People feel that it leads to a better expression of the domain model, because creating data and querying it are often radically different from the customer's perspective.

Whether or not that goal is achieved, I'm not sure. But that's the reason people are experimenting with patterns like that, as I see it.

Post reply on HN