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
Share this Scrolly Tale with your friends.
A Scrolly Tale is a new way to read Twitter threads with a more visually immersive experience.
Discover more beautiful Scrolly Tales like this.