فصل ۲ — کشف دانش دامنه

«آنچه وارد محیط Production می‌شود، برداشت ـ یا سوءبرداشت ـ توسعه‌دهندگان است، نه دانشی که متخصصان دامنه در ذهن دارند.»— Alberto Brandolini

در فصل قبل بررسی دامنه‌های کسب‌وکار را آغاز کردیم. آموختید دامنه‌های فعالیت یک شرکت را شناسایی کنید و راهبرد رقابتی آن را از طریق مرزها و انواع زیردامنه‌های کسب‌وکار تحلیل کنید.

این فصل بحث تحلیل دامنه را در بُعد دیگری ادامه می‌دهد: عمق. تمرکز بر داخل یک زیردامنه، کارکرد کسب‌وکاری و منطق آن است. ابزار DDD برای ارتباط مؤثر و اشتراک دانش، یعنی «زبان فراگیر» (Ubiquitous Language)، معرفی می‌شود. در اینجا از آن برای فهم ظرافت‌های دامنه استفاده می‌کنیم و در فصل‌های بعد برای مدل‌سازی و پیاده‌سازی منطق کسب‌وکار در نرم‌افزار.

مسائل کسب‌وکار

سامانه‌های نرم‌افزاری که می‌سازیم راه‌حل‌هایی برای مسائل کسب‌وکار هستند. در اینجا «مسئله» شبیه مسئلهٔ ریاضی یا معمایی نیست که یک‌بار حل شود و تمام. در دامنهٔ کسب‌وکار معنای گسترده‌تری دارد: چالش‌هایی مانند بهینه‌سازی گردش‌کار و فرایندها، کمینه کردن کار دستی، مدیریت منابع، پشتیبانی تصمیم، مدیریت داده و موارد مشابه.

مسائل کسب‌وکار هم در سطح دامنه و هم در سطح زیردامنه ظاهر می‌شوند. هدف شرکت حل مسائل مشتریان است. در مثال FedEx، مشتریان باید بسته‌هایشان در بازهٔ زمانی محدود جابه‌جا شود؛ بنابراین شرکت فرایند ارسال را بهینه می‌کند.

زیردامنه‌ها حوزه‌های مسئلهٔ ریزتری هستند که هدفشان فراهم کردن قابلیت کسب‌وکاری مشخص است. زیردامنهٔ مدیریت دانش ذخیره و بازیابی اطلاعات را بهینه می‌کند، زیردامنهٔ Clearing اجرای تراکنش‌های مالی را، و زیردامنهٔ حسابداری جریان وجوه شرکت را ثبت و پیگیری می‌کند.

کشف دانش

برای طراحی راهکار نرم‌افزاری مؤثر، دست‌کم باید دانش پایه‌ای از دامنهٔ کسب‌وکار داشته باشیم. این دانش متعلق به متخصصان دامنه است؛ وظیفهٔ آن‌ها تخصص یافتن و فهمیدن ظرافت‌های کسب‌وکار است. نه لازم است و نه واقعاً ممکن است ما خودمان متخصص کامل دامنه شویم، اما حیاتی است که آن‌ها را بفهمیم و همان اصطلاحات کسب‌وکاری را به‌کار ببریم.

نرم‌افزار مؤثر باید شیوهٔ اندیشیدن متخصصان دامنه دربارهٔ مسئله ـ مدل‌های ذهنی آن‌ها ـ را بازتاب دهد. اگر مسئلهٔ کسب‌وکار و منطق پشت نیازمندی‌ها را نفهمیم، کارمان به «ترجمهٔ» نیازمندی‌ها به کد محدود می‌شود. اگر نیازمندی یک حالت مرزی حیاتی را جا انداخته باشد چه؟ اگر مفهومی از کسب‌وکار اصلاً توصیف نشده باشد و مدل نتواند نیازهای آینده را پشتیبانی کند چه؟

به گفتهٔ Alberto Brandolini، توسعهٔ نرم‌افزار یک فرایند یادگیری است و کد کارا محصول جانبی آن است. موفقیت پروژه به اثربخشی اشتراک دانش میان متخصصان دامنه و مهندسان نرم‌افزار وابسته است. برای حل مسئله باید آن را بفهمیم.

ارتباطات

تقریباً همهٔ پروژه‌های نرم‌افزاری به همکاری نقش‌های گوناگون نیاز دارند: متخصصان دامنه، Product Ownerها، مهندسان، طراحان UI/UX، مدیران پروژه، آزمونگران، تحلیلگران و دیگران. نتیجه مانند هر فعالیت مشارکتی به کیفیت همکاری این افراد وابسته است. آیا همه دربارهٔ مسئله‌ای که حل می‌شود توافق دارند؟ آیا دربارهٔ راهکار یا نیازمندی‌های عملکردی و غیرعملکردی فرض‌های متناقضی وجود دارد؟ هم‌سویی در همهٔ مسائل پروژه برای موفقیت حیاتی است.

پژوهش دربارهٔ شکست پروژه‌ها نشان داده ارتباط مؤثر برای اشتراک دانش و موفقیت پروژه ضروری است. با این حال در عمل اغلب ارتباط مستقیم میان افراد کسب‌وکار و مهندسان وجود ندارد. دانش دامنه از متخصصان به مهندسان «هل داده» می‌شود و از میان واسطه‌ها یا «مترجمان» مانند تحلیلگران سیستم/کسب‌وکار، Product Ownerها و مدیران پروژه عبور می‌کند. شکل 2-1 این جریان رایج را نمایش می‌دهد.

در چرخهٔ سنتی توسعه، دانش دامنه به شکلی «دوست‌دار مهندس» به نام مدل تحلیل (Analysis Model) ترجمه می‌شود که بیشتر توصیف نیازمندی‌های سامانه است تا فهم دامنهٔ پشت آن. نیت خوب است، اما این واسطه‌گری برای انتقال دانش خطرناک است. در هر ترجمه بخشی از اطلاعات از دست می‌رود؛ در اینجا دانش دامنه‌ای که برای حل مسئله حیاتی است پیش از رسیدن به مهندسان ناقص می‌شود.

این تنها ترجمه نیست. مدل تحلیل به مدل طراحی نرم‌افزار یا سند طراحی، و آن هم به مدل پیاده‌سازی یا کد منبع ترجمه می‌شود. اسناد نیز معمولاً سریع قدیمی می‌شوند. در نهایت کد منبع وسیله‌ای برای انتقال دانش دامنه به مهندسانی است که بعداً سامانه را نگه می‌دارند. شکل 2-2 زنجیرهٔ این تبدیل‌ها را نشان می‌دهد.

این فرایند شبیه بازی کودکان «تلفن» است: افراد در صف می‌ایستند، نفر اول پیامی را در گوش نفر دوم می‌گوید و پیام تا آخر صف منتقل می‌شود. نفر آخر پیام شنیده‌شده را بلند اعلام می‌کند و معمولاً با پیام اصلی تفاوت قابل‌توجهی دارد. در پروژه نیز دانش دامنه تحریف می‌شود و نتیجه می‌تواند پیاده‌سازی راه‌حل اشتباه یا حتی راه‌حل درست برای مسئلهٔ اشتباه باشد؛ در هر دو حالت پروژه شکست می‌خورد.

DDD راه بهتری پیشنهاد می‌کند: انتقال دانش از متخصص دامنه به مهندس با استفاده از زبان فراگیر.

زبان فراگیر چیست؟

استفاده از زبان فراگیر یکی از بنیادی‌ترین شیوه‌های DDD است. ایده ساده است: اگر گروه‌ها می‌خواهند مؤثر ارتباط برقرار کنند، به‌جای اتکا به ترجمه‌های مکرر باید به یک زبان مشترک سخن بگویند.

این مفهوم تقریباً بدیهی به نظر می‌رسد، اما به قول Voltaire، «عقل سلیم چندان هم رایج نیست.» چرخهٔ سنتی توسعه ترجمه‌های پیاپی زیر را ایجاد می‌کند:

• دانش دامنه به مدل تحلیل
• مدل تحلیل به نیازمندی‌ها
• نیازمندی‌ها به طراحی سامانه
• طراحی سامانه به کد منبع

در مقابل، DDD می‌گوید یک زبان واحد برای توصیف دامنهٔ کسب‌وکار پرورش دهید: Ubiquitous Language.

تمام ذی‌نفعان پروژه ـ مهندسان، Product Ownerها، متخصصان دامنه، طراحان UI/UX و دیگران ـ باید هنگام صحبت دربارهٔ دامنه از همین زبان استفاده کنند. مهم‌تر از همه، متخصصان دامنه باید بتوانند با این زبان دربارهٔ کسب‌وکار استدلال کنند؛ زیرا زبان هم خود دامنه و هم مدل ذهنی متخصصان را بازنمایی می‌کند.

فقط با استفادهٔ مستمر از زبان فراگیر و اصطلاحات آن است که می‌توان درک مشترکی میان همهٔ ذی‌نفعان پرورش داد.

زبان کسب‌وکار

باید تأکید کرد زبان فراگیر زبان خود کسب‌وکار است؛ بنابراین باید فقط از اصطلاحات مرتبط با دامنه تشکیل شود، نه اصطلاحات فنی. هدف این نیست که متخصصان کسب‌وکار را با Singleton یا Abstract Factory آشنا کنیم. هدف، بیان مدل ذهنی آن‌ها از دامنه با اصطلاحاتی روشن و قابل‌فهم است.

سناریوها

فرض کنید روی سامانهٔ مدیریت کمپین تبلیغاتی کار می‌کنیم. جمله‌های زیر در زبان کسب‌وکار بیان شده‌اند:

• یک کمپین تبلیغاتی می‌تواند مواد خلاقهٔ متفاوتی نمایش دهد.
• کمپین تنها زمانی قابل انتشار است که دست‌کم یکی از Placementهای آن فعال باشد.
• کمیسیون فروش پس از تأیید تراکنش‌ها محاسبه می‌شود.

این جمله‌ها دید متخصصان دامنه را منعکس می‌کنند. اما جمله‌های زیر کاملاً فنی‌اند و در زبان فراگیر جای نمی‌گیرند:

• iframe تبلیغ یک فایل HTML را نمایش می‌دهد.
• کمپین فقط زمانی منتشر می‌شود که حداقل یک رکورد مرتبط در جدول active-placements داشته باشد.
• کمیسیون فروش بر پایهٔ رکوردهای متناظر در جدول‌های transactions و approved-sales است.

این بیان‌های فنی برای متخصص دامنه روشن نیستند. اگر مهندسان فقط همین دید فنی و راه‌حل‌محور را بشناسند، منطق واقعی کسب‌وکار و دلیل رفتار آن را کامل درک نمی‌کنند و توان مدل‌سازی و پیاده‌سازی راهکاری مؤثر محدود می‌شود.

سازگاری و دقت زبان

زبان فراگیر باید دقیق و سازگار باشد؛ نیاز به حدس و فرض را حذف و منطق دامنه را صریح کند. چون ابهام ارتباط را مختل می‌کند، هر اصطلاح باید یک و فقط یک معنا داشته باشد.

اصطلاحات مبهم

فرض کنید در یک دامنه واژهٔ policy دو معنا دارد: یک قاعدهٔ نظارتی و یک قرارداد بیمه. انسان‌ها در گفت‌وگوی مستقیم با توجه به زمینه معنا را تشخیص می‌دهند، اما نرم‌افزار با ابهام خوب کنار نمی‌آید و مدل‌سازی موجودیتی با نام «policy» دشوار می‌شود. زبان فراگیر یک معنای یکتا می‌خواهد؛ بنابراین باید دو مفهوم را صریحاً با اصطلاحات «regulatory rule» و «insurance contract» مدل کرد.

اصطلاحات مترادف

دو اصطلاح نیز نباید بدون دقت به‌جای هم استفاده شوند. بسیاری سامانه‌ها واژهٔ User را به‌کار می‌برند، اما در گفتار متخصصان ممکن است واژه‌هایی مانند user، visitor، administrator و account به‌ظاهر مترادف باشند.

مترادف‌ها ابتدا بی‌ضرر به نظر می‌رسند، اما اغلب مفاهیم متفاوتی را نشان می‌دهند. Visitor و Account هر دو از نظر فنی کاربر سامانه‌اند، ولی کاربر ثبت‌نشده و ثبت‌شده نقش و رفتار یکسانی ندارند. دادهٔ Visitor ممکن است عمدتاً برای تحلیل باشد، در حالی که Account واقعاً از قابلیت‌های سامانه استفاده می‌کند.

بهتر است هر اصطلاح در زمینهٔ دقیق خودش استفاده شود. فهم تفاوت آن‌ها مدل‌ها و پیاده‌سازی‌های ساده‌تر و روشن‌تری برای موجودیت‌های دامنه می‌سازد.

مدل دامنهٔ کسب‌وکار

مدل چیست؟

«مدل بازنمایی ساده‌شدهٔ یک چیز یا پدیده است که عمداً برخی جنبه‌ها را برجسته و برخی دیگر را نادیده می‌گیرد؛ انتزاعی که با کاربردی مشخص در ذهن ساخته می‌شود.»— Rebecca Wirfs-Brock

مدل کپی دنیای واقعی نیست، بلکه سازه‌ای انسانی است که کمک می‌کند سامانه‌های واقعی را بفهمیم. نمونهٔ کلاسیک مدل، نقشه است: نقشهٔ مسیریابی، توپوگرافی، جهان، مترو و انواع دیگر. شکل 2-3 چند مدل متفاوت از زمین را نمایش می‌دهد: جاده‌ها، منطقه‌های زمانی، ناوبری دریایی، عوارض زمین، ناوبری هوایی و مسیرهای مترو.

هیچ‌یک از این نقشه‌ها تمام جزئیات سیاره را نشان نمی‌دهد. هر نقشه فقط دادهٔ کافی برای هدف خاص خودش ـ مسئله‌ای که باید حل کند ـ در اختیار می‌گذارد.

مدل‌سازی مؤثر

هر مدل هدفی دارد و مدل مؤثر فقط جزئیاتی را نگه می‌دارد که برای آن هدف لازم‌اند. در نقشهٔ جهان ایستگاه مترو نمی‌بینید، و از نقشهٔ مترو هم نمی‌توان فاصلهٔ جغرافیایی دقیق را تخمین زد. هر نقشه فقط اطلاعات مناسب کار خودش را دارد.

این نکته ارزش تکرار دارد: مدل مفید کپی جهان واقعی نیست؛ برای حل یک مسئله ساخته می‌شود و فقط باید اطلاعات کافی برای همان هدف را ارائه کند. به قول George Box: «همهٔ مدل‌ها غلط‌اند، اما بعضی مفیدند.»

در اصل، مدل یک انتزاع (Abstraction) است. انتزاع کمک می‌کند با حذف جزئیات غیرضروری بر پیچیدگی غلبه کنیم و فقط چیزهای لازم برای مسئلهٔ فعلی را نگه داریم. انتزاع نامؤثر یا اطلاعات لازم را حذف می‌کند یا با نگه داشتن چیزهای غیرضروری نویز می‌سازد. Edsger W. Dijkstra در «The Humble Programmer» می‌گوید هدف انتزاع مبهم بودن نیست، بلکه ساخت سطح معنایی تازه‌ای است که در آن بتوان کاملاً دقیق بود.

مدل‌سازی دامنهٔ کسب‌وکار

وقتی زبان فراگیر را پرورش می‌دهیم، عملاً مدلی از دامنهٔ کسب‌وکار می‌سازیم. مدل باید مدل‌های ذهنی متخصصان دامنه و شیوهٔ اندیشیدن آن‌ها دربارهٔ عملکرد کسب‌وکار را ثبت کند. باید موجودیت‌های کسب‌وکاری و رفتارشان، رابطه‌های علت و معلولی و Invariantها را بازتاب دهد.

زبان فراگیر قرار نیست تمام جزئیات ممکن دامنه را پوشش دهد؛ چنین کاری همهٔ ذی‌نفعان را مجبور می‌کند متخصص کامل دامنه شوند. مدل باید فقط آن جنبه‌هایی را شامل شود که برای پیاده‌سازی سامانهٔ لازم و حل مسئلهٔ مشخص نرم‌افزار کافی‌اند. فصل‌های بعد نشان می‌دهند زبان فراگیر چگونه تصمیم‌های طراحی و پیاده‌سازی سطح پایین را هدایت می‌کند.

ارتباط مؤثر میان تیم مهندسی و متخصصان دامنه حیاتی است و با پیچیده‌تر شدن دامنه اهمیتش افزایش می‌یابد. هرچه دامنه پیچیده‌تر باشد مدل‌سازی و پیاده‌سازی منطق آن دشوارتر است؛ حتی یک سوءبرداشت کوچک از دامنهٔ پیچیده یا اصول زیرین آن می‌تواند به پیاده‌سازی پر از خطاهای جدی منجر شود. تنها راه قابل‌اعتماد برای آزمودن فهممان از دامنه، گفت‌وگو با متخصصان به زبانی است که می‌فهمند: زبان کسب‌وکار.

تلاش مستمر

شکل‌دادن زبان فراگیر نیازمند تعامل با صاحبان طبیعی آن، یعنی متخصصان دامنه است. فقط تعامل واقعی با آن‌ها می‌تواند خطاها، فرض‌های نادرست یا درک کلیِ معیوب از کسب‌وکار را آشکار کند.

همهٔ ذی‌نفعان باید در تمام ارتباطات پروژه از زبان فراگیر استفاده کنند تا دانش پخش و درک مشترک تقویت شود. این زبان باید در نیازمندی‌ها، آزمون‌ها، مستندات و حتی خود کد منبع پیوسته تکرار و تقویت شود.

مهم‌تر از همه، پرورش زبان فراگیر فرایندی پایان‌ناپذیر است. باید دائماً اعتبارسنجی و تکامل داده شود. استفادهٔ روزمره در طول زمان بینش‌های عمیق‌تری از دامنه آشکار می‌کند؛ هرگاه چنین کشفی رخ دهد زبان هم باید با دانش تازه تکامل یابد.

ابزارها

ابزارها و فناوری‌هایی وجود دارند که ثبت و مدیریت زبان فراگیر را آسان می‌کنند. برای مثال Wiki می‌تواند به‌عنوان واژه‌نامه برای ثبت اصطلاحات استفاده شود و ورود اعضای تازه به تیم را آسان کند، چون مرجع مشخصی برای اصطلاحات دامنه فراهم می‌آورد.

نگهداری واژه‌نامه باید تلاشی مشترک باشد. وقتی زبان تغییر می‌کند، همهٔ اعضای تیم باید بتوانند واژه‌نامه را به‌روزرسانی کنند؛ نه اینکه این مسئولیت فقط در اختیار رهبر تیم یا معمار باشد.

واژه‌نامه محدودیتی ذاتی دارد: برای «اسم‌ها» ـ نام موجودیت‌ها، فرایندها و نقش‌ها ـ عالی است، اما رفتار کسب‌وکار را خوب ثبت نمی‌کند. رفتار صرفاً فهرستی از فعل‌های مربوط به اسم‌ها نیست؛ منطق واقعی کسب‌وکار با قواعد، فرض‌ها و Invariantهایش است. این مفاهیم را بهتر است در کنار واژه‌نامه با ابزارهایی مانند Use Caseها یا آزمون‌های Gherkin ثبت کرد.

آزمون‌های خودکار نوشته‌شده با Gherkin علاوه بر ثبت زبان فراگیر، پلی میان متخصصان دامنه و مهندسان‌اند. متخصص دامنه می‌تواند آزمون را بخواند و رفتار مورد انتظار سامانه را تأیید کند. نمونهٔ کتاب:

Scenario: Notify the agent about a new support case
 Given Vincent Jules submits a new support case saying:
 """
 I need help configuring AWS Infinidash
 """
 When the ticket is assigned to Mr. Wolf
 Then the agent receives a notification about the new ticket

مدیریت مجموعه آزمون مبتنی بر Gherkin، به‌خصوص در ابتدای پروژه، ممکن است دشوار باشد، اما برای دامنه‌های پیچیده ارزش آن را دارد. البته نباید انتظار داشت خود متخصصان دامنه آزمون‌های Gherkin را بنویسند.

حتی ابزارهای تحلیل ایستای کد برای بررسی استفاده از اصطلاحات زبان فراگیر وجود دارد؛ NDepend نمونه‌ای قابل‌توجه است.

این ابزارها مفیدند، اما نسبت به استفادهٔ واقعی زبان در تعامل‌های روزمره نقش ثانویه دارند. از ابزار برای پشتیبانی مدیریت زبان استفاده کنید، نه به‌عنوان جایگزین استفادهٔ واقعی. همان‌طور که Agile Manifesto می‌گوید: «افراد و تعامل‌ها بر فرایندها و ابزارها اولویت دارند.»

چالش‌ها

در نظریه، پرورش زبان فراگیر ساده به نظر می‌رسد؛ در عمل چنین نیست. تنها راه قابل‌اعتماد برای جمع‌آوری دانش دامنه گفت‌وگو با متخصصان است. بخش مهمی از دانش معمولاً ضمنی (Tacit) است: نه مستند شده و نه کدگذاری، بلکه فقط در ذهن متخصصان وجود دارد. تنها راه دسترسی، سؤال پرسیدن است.

با تجربه بیشتر می‌بینید فرایند فقط کشف دانش موجود نیست، بلکه اغلب مدل را همراه متخصصان دامنه به‌صورت مشترک می‌سازید. حتی در فهم خود متخصصان هم ممکن است ابهام و نقاط سفید وجود داشته باشد؛ مثلاً فقط مسیر خوشحال (Happy Path) تعریف شده و Edge Caseهایی که فرض‌های رایج را به چالش می‌کشند نادیده مانده باشند. گاهی مفاهیم دامنه اصلاً تعریف صریح ندارند. پرسش دربارهٔ ماهیت کسب‌وکار این تضادها و نقاط سفید را آشکار می‌کند؛ وضعیتی که به‌ویژه در زیردامنه‌های هسته‌ای رایج است. در این حالت یادگیری دوطرفه است و شما به متخصصان هم برای فهم بهتر حوزه‌شان کمک می‌کنید.

وقتی DDD را وارد پروژهٔ Brownfield می‌کنید، معمولاً زبان از قبل شکل گرفته و ذی‌نفعان از آن استفاده می‌کنند. اما چون بر اساس اصول DDD ساخته نشده، ممکن است دامنه را خوب بازتاب ندهد؛ مثلاً نام جدول‌های پایگاه داده به‌عنوان اصطلاح کسب‌وکاری استفاده شود. تغییر زبان جاافتاده دشوار است و ابزار اصلی در اینجا صبر است. دست‌کم در جاهایی که کنترل بیشتری دارید ـ مستندات و کد منبع ـ زبان درست را به‌کار ببرید.

پرسش رایج دیگری این است که در شرکتی غیرانگلیسی‌زبان چه زبانی استفاده کنیم. توصیهٔ نویسنده این است که حداقل اسم‌های انگلیسی برای نام‌گذاری موجودیت‌های دامنه استفاده شوند؛ این کار استفاده از همان اصطلاحات در کد را آسان‌تر می‌کند.

نتیجه‌گیری

ارتباط مؤثر و اشتراک دانش برای موفقیت پروژهٔ نرم‌افزاری حیاتی است. مهندس باید دامنه را بفهمد تا بتواند راهکار مناسب طراحی و بسازد.

زبان فراگیر DDD ابزار مؤثری برای پر کردن فاصلهٔ دانشی میان متخصصان دامنه و مهندسان است. یک زبان مشترک می‌سازد که همهٔ ذی‌نفعان می‌توانند در گفتگو، مستندات، آزمون‌ها، نمودارها، کد منبع و سایر فعالیت‌های پروژه استفاده کنند.

برای ارتباط مؤثر، زبان باید ابهام و فرض‌های ضمنی را حذف کند. اصطلاحات باید سازگار باشند: نه یک اصطلاح با چند معنا و نه چند اصطلاح برای یک مفهوم بدون تمایز دقیق.

پرورش زبان فراگیر فرایندی مستمر است. با تکامل پروژه دانش تازه کشف می‌شود و این بینش‌ها باید در زبان منعکس شوند. Wiki و آزمون‌های Gherkin مدیریت و مستندسازی را آسان می‌کنند، اما پیش‌نیاز اصلی استفاده است: زبان باید در همهٔ ارتباطات پروژه به‌طور پیوسته استفاده شود.

تمرین‌ها

1. چه کسانی باید بتوانند در تعریف زبان فراگیر مشارکت کنند؟
   1. متخصصان دامنه
   2. مهندسان نرم‌افزار
   3. کاربران نهایی
   4. تمام ذی‌نفعان پروژه
2. زبان فراگیر در کجا باید استفاده شود؟
   1. گفتگوهای حضوری
   2. مستندات
   3. کد
   4. همهٔ موارد بالا
3. توضیح شرکت خیالی WolfDesk در مقدمه را مرور کنید. چه اصطلاحات دامنه‌ای در آن می‌بینید؟
4. یک پروژهٔ فعلی یا گذشته را در نظر بگیرید:
   1. مفاهیمی از دامنه پیدا کنید که بتوانید در گفتگو با متخصصان استفاده کنید.
   2. نمونه‌های اصطلاح ناسازگار را پیدا کنید: مفاهیمی با چند معنا یا یک مفهوم با نام‌های متفاوت.
   3. آیا ناکارآمدی توسعه‌ای دیده‌اید که از ارتباط ضعیف ناشی شده باشد؟
5. فرض کنید متخصصان واحدهای مختلف سازمان از یک واژهٔ مشترک، مثلاً policy، برای مفاهیم نامرتبط استفاده می‌کنند. زبان حاصل از مدل‌های ذهنی متخصصان شکل گرفته اما شرط «یک معنا برای هر اصطلاح» را نقض می‌کند. پیش از فصل بعد فکر کنید چگونه این مسئله را حل می‌کنید.

شکل‌ها و جدول‌های منبع

برای حفظ نمایش بصری دقیق عناصر گرافیکی، بازنمایی صفحه‌های دارای شکل یا جدول منبع در ادامه آمده است. متن آموزشی فصل در بخش‌های بالا به فارسی ترجمه شده است.