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.
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.
DDD?
An acronym for domain-driven design.
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.
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.
In theory, yes. In practice, not what happens. Throughout my experience I’ve seen business logic scattered everywhere.
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
