Why Domain Driven Design?

Post by marginalia_nu » Fri, Nov 25, 2022, 2:51 PM UTC

malaute wrote: post #91

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…

I'd argue though that the velocity and amount of functionality between those levels increased significantly.

Post by Garlef » Fri, Nov 25, 2022, 2:57 PM UTC

marcosdumay wrote: post #72

BulgarianIdiot wrote: post #39

Earlier quoted context omitted.

Exactly. We need RECURSIVE DIVISION of compute/state entities. Our main mistake is that we invent a level of division, and never make it recursive, i.e. a class is badly designed to be an entire module, it can't contain classes (inner Java classes are not what I'm talking about), nor can classes cross machine boundaries easily in many languages and so on. We need a unit of division that works across machines just as…

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.

Post by lakomen » Fri, Nov 25, 2022, 3:00 PM UTC

ki_ wrote: post #77

"In essence, all principles help you to model your software in a way that’s highly cohesive and loosely coupled- They are the building blocks of a well designed software." My suggestion, stay away from all these design patterns. In my experience, they lead to overly complex code because of all the structure. The best structure is the most simple one. "When you start thinking in abstractions and create abstractions in…

Post by larsonnn » Fri, Nov 25, 2022, 3:11 PM UTC

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…

Post by revskill » Fri, Nov 25, 2022, 3:18 PM UTC

ChicagoDave wrote: post #9

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

This is impractical in real world applications. Breaking complexity is much more than writing better code. DDD starts with listening to the subject matter experts (the business) and agreeing on language and models. You can write a hundred functions that look good, but if it isn’t aligned with how the business thinks, you will have built spaghetti code.