Thread by @refactorfiend

one way to look at it is that #domainDrivenDesign is the union of technical #objectOrientedDesign tightly coupled with subject matter expertise, business analysis and modeling. #ddd is #ood with soul. #ddDesign is #ooDesign done right

in complex systems, or enterprise development

different people/teams may have different
povs/ models/ experiences/ conceptualization/ understandings

of the subject matter or problem to be solved, and ...

👇🏾

they dont realize that there are these different povs; and even if they do,

they dont see the danger of coding to different concepts as long as it "works"; so inevitably ...

👇🏾

they have confusing communication and meetings

they step on each others toes

they burn a lot of unnecessary code/energy/business-dollars

👇🏾

a solution might be:

to harp on constant refinement of the concepts within the subject matter i.e. domain i.e. the problem to be solved, and then

to diligently marry those refined concepts to code elements named by words in the shared (ubiquitous) domain language

✊🏾

"DDD is OOD done right", where one of OOD basic approaches is to create classes and methods from nouns and verbs used by users describing the problem; then DDD looks at how that noun or verb fits within the deeper context of what the users actually need

and "what the users actually need" is something no one not even them may even fully understand right away. but it will come to light after repeated brainstorming and refining and refactoring sessions between users smes and devs

#knowledgeCrunching #madQuestionAsking