عنوان:

‫Domain-Driven Design (DDD)؛ بخش دوم: زبانی مشترک برای تیم‌ها

نویسنده: وحید نصیری
تاریخ: ۱۴۰۴/۰۵/۲۸ ۰۸:۱۰
آدرس: www.dntips.ir

تا به حال به این فکر کرده‌اید که چرا تیم‌های توسعه و تیم‌های کسب‌وکار اغلب در دو دنیای متفاوت زندگی می‌کنند؟ توسعه‌دهنده به «کلاس» و «متد» فکر می‌کند، در حالی که مدیر کسب‌وکار از «فرآیند ثبت نام مشتری جدید» یا «تخفیف فصلی» صحبت می‌کند. این شکاف زبانی، ریشه بسیاری از سوءتفاهم‌ها و پروژه‌های شکست‌خورده است. در همین نقطه است که Ubiquitous Language (زبان مشترک) وارد میدان می‌شود، یکی از کلیدی‌ترین مفاهیم در Domain-Driven Design (DDD).

زبان مشترک چیست؟

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

تصور کنید در حال ساخت یک سیستم بانکی هستید. ممکن است متخصصان کسب‌وکار از عبارت "انتقال وجه" برای عملیات جابجایی پول بین حساب‌ها استفاده کنند. یک توسعه‌دهنده ممکن است این را در کد خود با نام TransferFunds پیاده‌سازی کند. این دو واژه، هر دو یک مفهوم را بیان می‌کنند. اما اگر یک توسعه‌دهنده دیگر از واژه‌هایی مثل MoveMoney یا SendCash استفاده کند، در اینجا زبان مشترک شکسته می‌شود.

چرا این اهمیت دارد؟

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

به این فکر کنید: آیا تا به حال در پروژه‌ای بوده‌اید که در آن یک عبارت، معانی مختلفی برای افراد مختلف داشته باشد؟ اینجاست که زبان مشترک به عنوان یک ستون فقرات برای جلوگیری از چنین مشکلاتی عمل می‌کند.

چگونه زبان مشترک را ایجاد و حفظ کنیم؟

ایجاد زبان مشترک یک فرآیند مداوم است و نه یک کار یک‌باره.

گفتگو با متخصصان: بهترین راه برای کشف زبان مشترک، صحبت کردن مداوم با متخصصان کسب‌وکار (Domain Experts) است.
استفاده در همه جا: از این زبان در مکالمات، مستندات، نام‌گذاری کلاس‌ها، متدها، و متغیرها استفاده کنید.
ثبات و پایداری: همه اعضای تیم باید به این زبان پایبند باشند و هرگونه تغییر یا ابهام در آن را بلافاصله شناسایی و رفع کنند.

در نهایت، Ubiquitous Language فقط یک ابزار ارتباطی نیست، بلکه یک عنصر کلیدی در طراحی نرم‌افزار است. این زبان، به عنوان یک پل ارتباطی، به ما کمک می‌کند تا مدل نرم‌افزاری خود را به واقعیت کسب‌وکار نزدیک‌تر کنیم و نرم‌افزاری بسازیم که نه تنها کار می‌کند، بلکه به درستی نیز با پیچیدگی‌های جهان واقعی همخوانی دارد.

Domain-Driven Design: مبارزه با پیچیدگی‌های نرم‌افزاری

تا به حال در پروژه‌ای بوده‌اید که با افزایش تعداد ویژگی‌ها، به یک "کلاف سردرگم" تبدیل شده باشد؟ جایی که اضافه کردن یک قابلیت جدید، باعث بروز مشکلات غیرمنتظره در بخش‌های دیگر می‌شود و هر تغییری، زمان و انرژی زیادی را از تیم می‌گیرد.

این "پیچیدگی" (Complexity) است که به تدریج وارد کد ما می‌شود و آن را به یک سیستم غیرقابل نگهداری تبدیل می‌کند. Domain-Driven Design (DDD) به طور خاص برای مقابله با این پدیده طراحی شده است.

منشأ پیچیدگی

پیچیدگی نرم‌افزار از کجا می‌آید؟ اغلب از دو منشأ اصلی است:

۱. پیچیدگی ذاتی دامنه کسب‌وکار (Essential Complexity): این پیچیدگی ناشی از ماهیت خود مشکل است. برای مثال، قوانین مالیاتی یا فرآیندهای پیچیده در یک سیستم لجستیک. این نوع پیچیدگی قابل حذف نیست، اما می‌توان آن را مدیریت کرد.

2. پیچیدگی ناخواسته و تصادفی (Accidental Complexity): این پیچیدگی ناشی از انتخاب‌های نادرست در طراحی، معماری ضعیف یا کدنویسی غیرمنظم است. مثلاً استفاده از الگوهای نامناسب، وابستگی‌های زیاد بین ماژول‌ها و کد تکراری. این نوع پیچیدگی را می‌توان و باید حذف کرد.

هدف DDD، مدیریت پیچیدگی ذاتی و به حداقل رساندن پیچیدگی ناخواسته است.

چگونه DDD به ما کمک می‌کند؟

DDD با چند راهکار کلیدی، ما را در مسیر مبارزه با پیچیدگی یاری می‌دهد:

تمرکز بر هسته دامنه: DDD ما را تشویق می‌کند که تمام تمرکز خود را بر روی بخش‌های کلیدی و مهم کسب‌وکار بگذاریم و از جزئیات فنی که اغلب باعث ایجاد پیچیدگی ناخواسته می‌شوند، دوری کنیم.
مدل‌سازی دقیق: با استفاده از مفاهیمی مثل Entities، Value Objects و Aggregates، DDD به ما کمک می‌کند تا یک مدل دقیق و غنی از دنیای واقعی بسازیم. این مدل به عنوان یک نقشه راه برای حل مشکلات پیچیده عمل می‌کند.
تقسیم‌بندی به بخش‌های قابل مدیریت: مفاهیمی مثل Bounded Contexts به ما این امکان را می‌دهند که یک دامنه بزرگ و پیچیده را به بخش‌های کوچک‌تر و قابل مدیریت تقسیم کنیم. این کار مانند تقسیم یک نقشه بزرگ به نقشه‌های کوچک‌تر برای هر منطقه است، که درک و کار روی آن را آسان‌تر می‌کند.
زبان مشترک: همانطور که قبلاً اشاره شد، Ubiquitous Language ابهامات را از بین می‌برد و ارتباط بین اعضای تیم را بهبود می‌بخشد. این زبان مشترک، خود به کاهش پیچیدگی‌های ارتباطی منجر می‌شود.

با این رویکرد، ما دیگر با یک "مجموعه از جداول و کلاس‌ها" کار نمی‌کنیم، بلکه با یک "سیستم" کار می‌کنیم که منطق و رفتارش به طور مستقیم با دنیای واقعی کسب‌وکار همخوانی دارد. این همخوانی، کلید اصلی غلبه بر پیچیدگی است، زیرا به ما اجازه می‌دهد تا به جای درگیر شدن با مشکلات فنی، بر حل چالش‌های اصلی کسب‌وکار تمرکز کنیم.

در نهایت، می‌توان گفت که DDD نه یک راه حل جادویی، بلکه یک فلسفه و یک جعبه‌ابزار است که به ما کمک می‌کند تا آگاهانه با پیچیدگی روبرو شویم و با ابزارهای مناسب، بر آن غلبه کنیم.

مطالب مشابه

مسیرراه‌هاDomain-Driven Design (DDD)

مطالبDomain-Driven Design (DDD)؛ بخش اول: مقدمه و آشنایی با مفاهیم پایه DDD

مطالبچه زمانی نباید از DDD استفاده کنیم؟ راهنمای عملی برای توسعه‌دهندگان دات‌نت

مطالبDomain-Driven Design (DDD)؛ بخش سوم: تکنیک‌های کشف و درک دقیق دامنه کسب‌وکار

مطالبDomain-Driven Design (DDD)؛ بخش چهارم: Bounded Contexts

مطالبهنر استثناهای سفارشی در توسعه نرم‌افزار با NET.: رویکردی بر پایه طراحی دامنه محور (DDD)

نظرات مطالبDomain-Driven Design (DDD)؛ بخش سوم: تکنیک‌های کشف و درک دقیق دامنه کسب‌وکار

نظرات مطالبDomain-Driven Design (DDD)؛ بخش دوم: زبانی مشترک برای تیم‌ها

نظرات مطالبDomain-Driven Design (DDD)؛ بخش سوم: تکنیک‌های کشف و درک دقیق دامنه کسب‌وکار

نظرات مطالبDomain-Driven Design (DDD)؛ بخش اول: مقدمه و آشنایی با مفاهیم پایه DDD

نظرات

وحید نصیری در ۱۴۰۴/۰۵/۲۸ ۰۹:۱۶

یک مثال از کشف زبان فراگیر/مشترک: پلی میان ذهن و کد در دنیای طراحی دامنه‌محور

تصور کنید در یک تیم .NET، جایی که از EF-Core برای نقشه‌برداری مدل‌های دامنه به دیتابیس استفاده می‌کنید. بدون یک زبان مشترک، ممکن است یک توسعه‌دهنده "Order" را به عنوان یک Entity ساده ببیند که فقط فیلدهایی مثل Id و Date دارد، در حالی که برای کارشناس دامنه، "Order" شامل وضعیت‌هایی مثل "در حال پردازش" یا "لغو شده" است که رفتارهای خاصی را ایجاب می‌کند. Ubiquitous Language شما را وادار می‌کند تا این مفاهیم را با هم هم‌راستا کنید. نتیجه؟ کدی که نه تنها کار می‌کند، بلکه "صحبت" می‌کند – کدی که خواننده‌اش را به یاد دامنه واقعی می‌اندازد.

بیایید یک مثال واقعی را کاوش کنیم. فرض کنید در حال توسعه یک سیستم مدیریت سفارشات هستید. در DDD، ابتدا با کارشناسان دامنه گفتگو می‌کنید تا زبانشان را بفهمید: کلماتی مثل "Basket" برای سبد خرید، "Checkout" برای نهایی‌سازی، و "Shipment" برای ارسال. حالا این زبان را به کد .NET بیاورید. در EF-Core، مدل‌های دامنه‌تان (Entities و Value Objects) باید این زبان را منعکس کنند. مثلاً:

به جای یک کلاس ساده Order با پراپرتی‌های ژنریک، یک Aggregate Root به نام Order بسازید که متدهایی مثل AddItem() یا ConfirmShipment() داشته باشد – دقیقاً همان کلماتی که در دامنه استفاده می‌شود.
در DbContext EF-Core، وقتی مدل را کانفیگ می‌کنید، از Fluent API استفاده کنید تا روابط را با اصطلاحات دامنه توصیف کنید: modelBuilder.Entity<Order>().HasMany(o => o.Items).WithOne(); اما چرا متوقف شویم؟ نام‌گذاری‌ها را فراگیر/مشترک کنید: به جای Items， بگویید OrderLines اگر این اصطلاح در دامنه رایج است.

می‌بینید چقدر این رویکرد، کد را زنده می‌کند؟ حالا فکر کنید اگر این زبان را نادیده بگیرید: ممکن است در Repositoryها متدهایی مثل GetById() داشته باشید، اما بدون انعکاس دامنه، تیم بعداً گیج شود که "این Id دقیقاً به چه اشاره دارد؟" Ubiquitous Language شما را تشویق می‌کند تا Repositoryها را با متدهایی مثل FindPendingOrders() طراحی کنید – زبانی که مستقیماً از گفتگوهای دامنه می‌آید.

البته، ساخت این زبان آسان نیست. چالش‌هایی مثل تفاوت‌های فرهنگی در تیم یا تغییرات دامنه وجود دارد. اما تصور کنید اگر از ابتدا شروع کنید: جلسات مدلینگ دامنه (Event Storming) برگزار کنید، جایی که همه با هم کلمات کلیدی را استخراج می‌کنند. سپس، این کلمات را در کد، تست‌های BDD (مثل SpecFlow در .NET) و حتی کامنت‌ها بگنجانید. در EF-Core، وقتی Migrationها را می‌سازید، نام جدول‌ها و ستون‌ها را با همین زبان هم‌خوان کنید – مثلاً جدول Orders با ستون ShipmentStatus به جای چیزی مبهم مثل Stat.

مزایا؟ کدی که نگهداری‌اش آسان‌تر است، چون هر تغییری در دامنه، مستقیماً به کد ترجمه می‌شود. کمتر باگ، چون ابهام کمتری وجود دارد. و مهم‌تر، تیمی که احساس می‌کند بخشی از یک داستان بزرگ‌تر است. حالا نوبت شماست: در پروژه بعدی‌تان، سعی کنید یک مفهوم دامنه را انتخاب کنید و ببینید چطور می‌توانید زبان فراگیر/مشترک را اعمال کنید. آیا "Customer" در کدتان همان معنایی را دارد که در ذهن کارشناسان؟ کاوش کنید، آزمایش کنید – و ببینید چطور همه چیز هم‌راستا می‌شود.

بالازاده در ۱۴۰۴/۰۵/۲۸ ۱۲:۵۰

آیا می‌توان مرز مناسبی برای استفاده از عبارات به زبان اصلی تیم(فارسی) و عبارات انگلیسی در پروژه‌های داخلی(غیر بین‌المللی) با نیروی کار داخلی بیان کرد؟

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

استفاده این گروه بیشتر از واژگانِ فارسی است. به طور مثال برای کلمه بیمه از Insurance استفاده نمی‌کنند و یا برای برونسپاری نمونه از Sample Outsourcing استفاده نمی‌کنند. آیا تیم توسعه هم از Bimeh یا Sazman یا ErsalNemooneh و یا حتی عبارت‌های ترکیبی مانند ErsalSample استفاده کند؟ ممکن است جواب این باشد که همانگونه که در این مطلب بیان شد کل تیم باید در این‌باره تصمیم بگیرد ولی آیا تجربه‌هایی برای شفاف‌تر شدن حد و مرز این تصمیم‌ها وجود دارد؟

وحید نصیری در ۱۴۰۴/۰۵/۲۸ ۱۳:۱۰
برخی تیم‌ها مرز را این‌طور می‌کشند: نام‌های دامنه‌محور (Entities, Value Objects) را به زبان محلی بنویسید، اما ساختارهای فنی (متدهای ژنریک مثل Get یا Save) را انگلیسی نگه دارید. این کار، کد را خواناتر می‌کند برای کسانی که با دامنه آشنا هستند، بدون اینکه با ابزارهایی مثل EF-Core یا IDEها تداخل ایجاد کند. در تجربیات دیگر، به ویژه در فروم‌های فنی، توسعه‌دهندگان غیرانگلیسی‌زبان اشاره کرده‌اند که استفاده از زبان محلی در کد، گفتگو با کارشناسان دامنه را آسان‌تر می‌کند – مثلاً در یک پروژه آلمانی، "Kunde" به جای "Customer" استفاده شده تا تیم پشتیبانی احساس کند کد بخشی از دنیای آن‌هاست. الگوهای عمومی در کشورها مختلف نشان می‌دهد که در پروژه‌های داخلی، اولویت با زبانی است که تیم پشتیبانی – به عنوان لایه ارتباطی با مشتری – استفاده می‌کند. اگر آن‌ها از "سازمان" می‌گویند، چرا کد "Sazman" نداشته باشد؟ این کار، نه تنها Ubiquitous Language را تقویت می‌کند، بلکه چرخه بازخورد را سریع‌تر می‌کند – وقتی باگ گزارش می‌شود، همه دقیقاً می‌دانند "ErsalNemooneh" یعنی چه. اما مرز عملی: اگر اصطلاح فنی است (مثل "Database" یا "Query")، انگلیسی بماند تا با مستندات .NET هم‌خوان باشد. تجربیات نشان می‌دهد تیم‌هایی که این مرز را با جلسات مشترک (مثل Event Storming) تعیین می‌کنند، کمتر با ابهام روبرو می‌شوند.

در کل، زبان مشترک، یک زبان رسمی و مشترک است که توسط همه اعضای تیم، شامل توسعه‌دهندگان، تحلیلگران کسب‌وکار، متخصصان دامنه و حتی تیم‌های پشتیبانی فنی، برای توصیف مفاهیم، فرآیندها و قوانین کسب‌وکار استفاده می‌شود. هدف اصلی این زبان، از بین بردن سوءتفاهم‌ها و اطمینان از این است که همه افراد از یک چیز واحد صحبت می‌کنند.
این زبان مشترک باید:
- ثابت و یکپارچه باشد و در همه مستندات، کدها، مکالمات و حتی نام‌گذاری متغیرها و کلاس‌ها استفاده شود.
- مبتنی بر دامنه باشد، نه بر اساس مفاهیم فنی. به عبارت دیگر، باید مفاهیم کسب‌وکار را به درستی منعکس کند.
مرز استفاده از واژگان فارسی و انگلیسی
تجربه نشان می‌دهد که هیچ قانون یکسان و مطلقی برای همه پروژه‌ها وجود ندارد، اما می‌توان راهکارهایی را برای تعیین یک مرز مناسب ارائه داد:

۱. اصل اول: تمرکز بر وضوح و فهم
مهم‌ترین اصل این است که زبانی انتخاب شود که بیشترین وضوح و کمترین ابهام را برای همه اعضای تیم داشته باشد. زبان مشترک قرار نیست صرفاً یک زبان برنامه‌نویسی باشد؛ بلکه ابزاری برای ارتباط است.

۲. در نظر گرفتن سطح فنی و زبانی تیم
- اگر تیم توسعه و پشتیبانی، با واژگان فارسی کسب‌وکار ارتباط راحت‌تری دارند: استفاده از کلمات فارسی در کد و مستندات می‌تواند به کاهش سوءتفاهم‌ها کمک کند. برای مثال، استفاده از Bimeh به جای Insurance برای تیمی که واژه فارسی آن را به صورت روزمره استفاده می‌کند، کاملاً منطقی است. این کار به تیم پشتیبانی کمک می‌کند تا به راحتی با کدهای توسعه‌دهنده ارتباط برقرار کنند و بالعکس.
- استفاده از فینگیلیش (Finglish): در این حالت، می‌توان از ترکیبی از کلمات فارسی با املای انگلیسی استفاده کرد. مثلاً ersal_nemooneh یا takhfif_dadan. این رویکرد، در پروژه‌های داخلی بسیار رایج است و اغلب کارایی بالایی دارد، زیرا هم برای برنامه‌نویسان قابل فهم است و هم به مفاهیم کسب‌وکار نزدیک است.
۳. تعیین قوانین نام‌گذاری (Naming Conventions)
تیم باید در یک جلسه مشترک، با حضور همه ذی‌نفعان (توسعه، پشتیبانی، تحلیلگر)، تصمیم بگیرد که کدام واژگان فارسی و کدام واژگان انگلیسی استفاده شوند. چند راهکار عملی:
- واژگان خاص دامنه: برای مفاهیم کسب‌وکار که تیم به طور روزمره از واژه فارسی آن‌ها استفاده می‌کند (مانند بیمه، برونسپاری، سازمان، تخفیف)، بهتر است از همان کلمات فارسی (مثلاً Bimeh) استفاده شود. این کلمات هویت دامنه شما هستند.
- واژگان فنی و عمومی: برای مفاهیم عمومی‌تر و فنی که معادل انگلیسی آن‌ها در دنیای برنامه‌نویسی رایج است (مانند user, password, login, service), بهتر است از همان واژگان انگلیسی استفاده شود تا ابهام کاهش یابد.
۴. پرهیز از ترکیب‌های مبهم
ترکیب فارسی و انگلیسی به صورت نامنظم و بدون قاعده، می‌تواند باعث سردرگمی شود. به عنوان مثال، ErsalSample ممکن است برای برخی ابهام‌آمیز باشد. آیا منظور ارسال نمونه است یا چیز دیگری؟ تصمیم تیم باید بر یکی از دو الگو باشد:
- الگوی خالص فارسی:ersal_nemooneh
- الگوی خالص انگلیسی:send_sample
اگر زبان مشترک بر پایه واژگان فارسی است، بهتر است برای کلمات مرکب هم از همان فارسی استفاده شود.

مثال عملی
تصور کنید تیم شما یک سیستم برای یک شرکت بیمه داخلی می‌سازد.
- زبان مشترک فارسی:
- کلاس‌ها:Bimeh, Moshteri, Pardakht
- متدها:sabt_bimenameh, check_vaziat_sanad
- تیم پشتیبانی: به راحتی با این کلمات ارتباط برقرار می‌کند.
- توسعه‌دهنده: کد خوانا و مرتبط با دامنه می‌نویسد.
نتیجه‌گیری
بله، می‌توان مرز مناسبی تعیین کرد، اما این مرز باید توسط خود تیم و با توجه به شرایط خاص پروژه و سطح دانش همه اعضا مشخص شود.
توصیه می‌شود:
- جلسه‌ای مشترک برگزار کنید و در مورد زبان مشترک تصمیم‌گیری کنید.
- یک فرهنگ لغت (Glossary) از واژگان کلیدی دامنه تهیه کنید و همه مفاهیم را در آن تعریف کنید.
- به صورت منظم زبان مشترک را بازبینی کنید و در صورت لزوم آن را اصلاح کنید.

وحید نصیری در ۱۴۰۴/۰۵/۲۸ ۱۳:۴۸

واقعیت این است که در زبان مشترک (Ubiquitous Language) معیار اصلی وضوح و هم‌فهمی برای کل تیم است — نه زبان فارسی بودن یا انگلیسی بودن واژه. با توجه به تجربه‌هایی که در تیم‌های واقعی وجود دارد، می‌توان چند نکته راهنمای عملی برای «حد و مرز» این تصمیم‌گیری ذکر کرد:

چه زمانی واژه فارسی (یا فینگلیش) مناسب‌تر است؟

حالت	توضیح
واژه در تعاملات روزمره‌ی کاربران یا پشتیبانی به همین شکل استفاده می‌شود	مثال: بیمه، نمونه، سازمان در گفتگوهای واقعی به همین صورت گفته می‌شوند
تیم فنی نیز همین واژه را در مکالمات استفاده می‌کند	وقتی کسی در جلسه می‌گوید «ارسال نمونه» و نه «Send Sample»
واژه‌ی انگلیسی معادل یا از نظر بار معنایی دقیق نیست	مثلا “Claim” در DDD حوزه بیمه ممکن است بار خاصی داشته باشد، ولی در یک پروژه داخلی ساده «درخواست خسارت» دقیق‌تر فهمیده می‌شود
امکان سوء‌برداشت در صورت استفاده از انگلیسی وجود دارد	گاهی «Sample» در انگلیسی برای تیم فنی به معنی نمونه کد برداشت می‌شود و با «نمونه آزمایشگاهی» اشتباه می‌شود

چه زمانی بهتر است واژه انگلیسی بکار برده شود؟

حالت	توضیح
دامنه دارای اصطلاحات استاندارد بین‌المللی است	مثال: API، OAuth، SLA – معادل فارسی بیشتر مبهم است
بخشی از تیم (یا تیم آینده) با منابع انگلیسی کار می‌کند	مثال: توسعه‌دهندگانی که محصول مشابه یا داکیومنت‌ خارجی را مطالعه می‌کنند
ترجمه فارسی نسبتاً طولانی یا نامأنوس است	مثل «برون‌سپاری نمونه» که بیشتر از خود «Sample Outsourcing» نامأنوس‌تر به‌نظر می‌رسد
اصطلاح در کد یا دیاگرام‌ها زیاد تکرار می‌شود و نسخه فارسی/فینگلیش خوانایی را کم می‌کند	مثلا SazmanSpecification یا BimehPolicy طولانی و ناخوانا می‌شود

در ادامه یک نمونه ساده از Domain Glossary (زبان مشترک) برای یک پروژه در دامنه «بیمه و ارسال نمونه» آورده‌ شده تا ببینید چطور می‌توان واژه‌ها را به‌صورت واحد و توافق‌شده ثبت کرد:

مثال: دیکشنری زبان مشترک (Ubiquitous Language Glossary)

واژه	شکل استفاده در گفتگو	شکل استفاده در کد	توضیح
بیمه	بیمه	`Bimeh`	قرارداد بیمه بین مشتری و شرکت
سازمان	سازمان	`Sazman`	سازمانی که با شرکت همکاری دارد
نمونه	نمونه	`Nemooneh`	نمونه آزمایش‌ یا مستندی که باید ارسال شود
ارسال نمونه	ارسال نمونه	`ErsalNemooneh`	روند ارسال نمونه توسط سازمان به شرکت
درخواست خسارت	درخواست خسارت	`DamageRequest`	فرم یا فرآیند درخواست جبران خسارت
SLA	SLA	`SLA`	توافق‌نامه سطح خدمت (واژه انگلیسی نگه داشته شده)
API	API	`API`	رابط برنامه‌نویسی (همان اصطلاح رایج)

نکات همراه با Glossary

از ترکیب فارسی و انگلیسی صرفاً بر اساس وضوح استفاده شده:
چون همه “SLA” یا “API” را با همین اسم می‌شناسند، ترجمه نشده‌اند.
اما “Insurance” عملاً در مکالمه کسی استفاده نمی‌کرد → “بیمه” انتخاب شده.
این جدول در ابتدای پروژه تهیه می‌شود و در طول توسعه به‌روز می‌گردد (وقتی واژه جدیدی وارد دامنه شد).
در جلسات، اگر کسی اصطلاح دیگری استفاده کرد (مثلاً “Sample” به‌جای “نمونه”) → سریع به جدول ارجاع می‌شود و یکی از آنها به‌عنوان‌ واژه واحد ثبت می‌گردد.

جمع‌بندی

در DDD مهم نیست که واژه فارسی، انگلیسی یا فینگلیش باشد — مهم این است که واحد و بی‌ابهام باشد و دقیقاً در گفتگوها، مستندات و کد به یک شکل استفاده شود.

بنابراین اگر تیم پشتیبانی اصطلاحاتی مثل «ارسال نمونه» یا «سازمان» را کاملاً طبیعی و شفاف استفاده می‌کند، هیچ ایرادی ندارد که در کد نیز ErsalNemoonehService یا حتی ارسال_نمونه‌ داشته باشید — به شرط اینکه برای همه کاملاً قابل فهم باشد و نوسان بین “Sample” و “نمونه” پیش نیاید.