Why Domain Driven Design?

#1

Post by sni » Wed, Nov 23, 2022, 8:06 PM UTC

Why Domain Driven Design?
yehohanan7.medium.com

Re: Why Domain Driven Design?

#2

Post by revskill » Fri, Nov 25, 2022, 9:29 AM UTC

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: You lack of experience in making complicated/complex software ! No, it's you lack ability to produce simple software, it's your fault.

Re: Why Domain Driven Design?

#3

Post by badcppdev » Fri, Nov 25, 2022, 9:35 AM UTC

I'm not a DDD advocate but it worries me that the blog author has not referenced the 2003 Eric Evans book "Domain-Driven Design: Tackling Complexity in the Heart of Software".

Re: Why Domain Driven Design?

#4

Post by RamblingCTO » Fri, Nov 25, 2022, 9:40 AM UTC

It's very easy: if your software gets complex enough you abstracted so much stuff (service layers implementing common actions) that everything is interwoven. You're blocking yourself from iterating. You can't react to changes in requirements or do isolated refactoring. If your logic is encapsulated (and with a sprinkle of hexagonal) you have no problem. If everything is connected you touch lots and lots of features. Also a problem is feature retirement. With DDD you just delete the class/file/function.

Re: Why Domain Driven Design?

#5

Post by BulgarianIdiot » Fri, Nov 25, 2022, 9:43 AM UTC

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

Re: Why Domain Driven Design?

#6

Post by Pandabob » Fri, Nov 25, 2022, 9:44 AM UTC

For all the Python devs reading this, a book that aims to cover DDD from a Python perspective is Architecture Patterns With Python [1]. It's free to read online and all the code can be found in Github.

[0]: https://www.cosmicpython.com/

Re: Why Domain Driven Design?

#7

Post by turtleyacht » Fri, Nov 25, 2022, 9:45 AM UTC

DDD sounds amazing, but y'all the pull requests are usually a dozen files with tiny changes. At least from what I have seen.

And the promise is "change is easy" or "impact to existing code is low." This may be true. Is it?

I have the Evans book. It may completely change the way I write code. But I also have "C Interfaces and Implementations," and that promises another. Yet another is Stepanov's "Elements of Programming," which by first chapter's end Feynman is telling me to read it again [1].

We just want to make Good Decisions about the code, right? Strategically (architectures) and tactically (pure functions).

I wonder if domain stuff surfaces naturally in SQL. Tables as types and subtypes. "Now build an app around me" feels like a different take from the usual "Now we just need the persistence layer."

[1] No Ordinary Genius: The Illustrated Richard Feynman

Re: Why Domain Driven Design?

#8

Post by kqr » Fri, Nov 25, 2022, 9:47 AM UTC

badcppdev wrote: post #3

I'm not a DDD advocate but it worries me that the blog author has not referenced the 2003 Eric Evans book "Domain-Driven Design: Tackling Complexity in the Heart of Software".

I think even Eric Evans himself have said that the book you mention brings up concepts in the wrong order. By focusing on small details first, it has confused people into thinking those small details are the important parts. The important bits are the ones that come last in the book.

Re: Why Domain Driven Design?

#9

Post by ChicagoDave » Fri, Nov 25, 2022, 9:49 AM UTC

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.

Re: Why Domain Driven Design?

#10

Post by ssivark » Fri, Nov 25, 2022, 9:53 AM UTC

turtleyacht wrote: post #7

DDD sounds amazing, but y'all the pull requests are usually a dozen files with tiny changes. At least from what I have seen. And the promise is "change is easy" or "impact to existing code is low." This may be true. Is it? I have the Evans book. It may completely change the way I write code. But I also have "C Interfaces and Implementations," and that promises another. Yet another is Stepanov's "Elements of Programmi…

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