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