this post was submitted on 13 May 2026
10 points (70.8% liked)

Programming

26915 readers
547 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
 

Contrary to what many people believe in the DDD community, in my opinion, we’re not here to become domain experts; we’re here to build software.

top 8 comments
sorted by: hot top controversial new old
[–] MagicShel@lemmy.zip 21 points 1 day ago

So I have frequently worked in projects where I don't know how end users interact with the software. I can make code hum without knowing how it fits into the ecosystem. Sometimes that's all the job is because that's the structure.

That said, I can contribute a lot more if I do understand the bigger picture. Domain knowledge helps me triage. It helps me propose effective alternatives. I'd say it is critical for understanding separation of concerns and deciding what compromises to recommended practices are reasonable.

I reject this principle. You can write code without domain knowledge, but software by itself has no purpose until it meets users. And to write software that works best for users you have to understand them.

[–] Ephera@lemmy.ml 8 points 1 day ago

Having a third arm, so you can continue typing and also facepalm at the same time does seem quite good.

[–] SW42@lemmy.world 14 points 1 day ago

Experts no, but if you know what it’s about the software can be more user friendly, more robust and simpler. Otherwise you have to believe the domain experts and their mental model of how the processes and transactions work, which is not always near to reality

[–] MonkderVierte@lemmy.zip 2 points 1 day ago (2 children)
[–] talkingpumpkin@lemmy.world 2 points 1 day ago (2 children)

domain-driven design (or development?)

I'm not 100% what it is (I'm really not into nomenclature), but I think it's the practice of modeling your software after the domain you are working in... IDK if/how it differs from what everyone has always been doing since forever.

[–] vrek@programming.dev 2 points 1 day ago

My understanding is there was a group that was saying to combine stuff by use. So you have a class to determine total price, but you sell liquids priced by liter, gasses sold by cubic foot, and solids sold by quantity. Each of those are controlled by separate departments and require different methods of calculating price.

DDD basically says to group everything for liquids together, everything for gasses together and same for solids. Don't group by process but by who uses them.

[–] rafaelfcsouza@feddit.org 1 points 1 day ago

In theory, yes. In practice, not what happens. Throughout my experience I've seen business logic scattered everywhere.