در جلساتی که توسعه دهندگان نرم افزار با متخصصین حوزه کاری (Domain)، برگزار می کنند، طیف وسیعی از واژگان و اصطلاحات هم توسط توسعه دهندگان و هم توسط متخصصین دامین، بکار گرفته می شود. بسیار پیش آمده که هر چند هر دو گروه از واژه مشترکی استفاده می کنند، اما آن چیزی که در ذهنشان نسبت به آن واژه وجود دارد، متفاوت از یکدیگر است.
مثالی بزنم تا موضوع روشن تر شود. فرض کنید در نرم افزاری که مشغول طراحی آن هستید افراد متخصص حوزه کاری (Domain Experts) و نیز اعضای تیم توسعه از واژه "کاربر" استفاده می کنند. اما آیا منظور هر دو گروه از "کاربر" دقیقا یکسان است؟ الزاما خیر. ممکن است "کاربر" در ذهن متخصص دامین به معنی کسی باشد که به وب سایت مراجعه می کند حتی بدون داشتن حساب کاربری (Anonymous User). در حالی که توسعه گر تصور کند که کاربر کسی است که حتما در سایت دارای حساب کاربری است.
اریک اوانس در کتاب خود (Domain-Driven Design: Tackling Complexity in the Heart of Software) وضعیت وخیمی را تصویر کرده است که "زبان مشترک" برای گفتگو وجود ندارد:
A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of design.
The terminology of day-to-day discussions is disconnected from the terminology embedded in the code (ultimately the most important product of a software project). And even the same person uses different language in speech and in writing, so that the most incisive expressions of the domain often emerge in a transient form that is never captured in the code or even in writing.
Translation blunts communication and makes knowledge crunching anemic.
Yet none of these dialects can be a common language because none serves all needs.
تاکید بر دست یابی به "زبان مشترک" در DDD برای جلوگیری از پدید آمدن همین فهم های متفاوت در حین جلسات تحلیل است. با رعایت این نکته که "زبان مشترک" باید واژگانی باشد مرتبط با حوزه کسب و کار نرم افزار، و نه واژگانی فنی. بهتر است فهرست این واژگان توسط متخصصین دامین تدوین شود و توسعه دهندگان از این ترمینولوژی تبعیت کنند. علاوه بر این تاکید می شود تا از همین واژگان هم برای نامگذاری موجودیتهای دامین در حین طراحی استفاده شود. موفقیت در تعریف و تثبیت "زبان مشترک" یک فعالیت مهم و اساسی در DDD است که ماحصل آن نزدیک شدن ذهن و زبان توسعه دهندگان نرم افزار به ذهن و زبان "متخصصین دامین" است. این زبان مشترک با هر چه بیشتر شدن گفتگو بین توسعه دهندگان و متخصصین دامین، غنی تر و کامل تر و از ابهامات موجود خالی تر می شود.
به روز نگه داشتن "زبان مشترک" کار دشواری است و لازم است تا همواره دامین طراحی شده و "زبان مشترک" با هم سینک نگه داشته شوند. مثلا اگر تعریف "کاربر" عوض شد لازم است تا کدهای نوشته شده و مدل ایجاد شده هم به سرعت با تعریف جدید سازگار شود. همچنین لازم است تا همه افراد فعال در پروژه را ملزم کرد تا "زبان مشترک" را برای فعالیتهای خود مانند نوشتن، ترسیم نمودار، کد نویسی و صحبتهای شفاهی بکار گیرند.
مسلما همه ما تجربه بهتری خواهیم داشت وقتی که مطمئن باشیم درک همه مان از واژه "کاربر" ، "کسی است که در سایت دارای حساب کاربری فعال است". اگر غیر از این باشد می توانید موفقیتی برای پروژه تصور کنید؟
قطعا گفتگوی مستمر، شفاهی و رو در رو بین توسعه دهندگان و متخصصین دامین، بهترین روش برای دست یابی به "زبان مشترک" است. از همین روست که نقشهایی مانند Onsite Customer یا Product Owner و جلساتی مانند Sprint Planning یا Demo با اکوسیستم DDD همخوانی بیشتری دارند.
توجه کنیم به اینکه هر چند "زبان مشترک" زبانی است غیر فنی، اما پیش می آید که حاوی واژگان به ظاهر فنی هم باشد. مثلا واژه "صفحه بندی(Paging)". نکته ظریف اینکه این واژه فنی به دلیل اینکه امروزه در بسیاری از وب سایتها و برنامه های کاربردی مورد استفاده قرار گرفته است، دیگر به واژه ای تبدیل شده است که با احتمال بسیار بالا می توان گفت هر دو گروه توسعه دهندگان و متخصصین دامین ذهنیت مشترکی نسبت به آن دارند. همه می دانند که منظور چیست. لذا این واژه استفاده عام دارد و دیگر چندان واژه ای فنی محسوب نمی شود. لذا می توان آن را در تدوین "زبان مشترک" مورد استفاده قرار داد.
بنابراین:
Use the model as the backbone of a language. Commit the team to exercising that language relentlessly in all communication within the team and in the code. Use the same language in diagrams, writing, and especially speech.
Iron out difficulties by experimenting with alternative expressions, which reflect alternative models. Then refactor the code, renaming classes, methods, and modules to conform to the new model. Resolve confusion over terms in conversation, in just the way we come to agree on the meaning of ordinary words.
Recognize that a change in the UBIQUITOUS LANGUAGE is a change to the model.
Eric Evans
Domain-Driven Design: Tackling Complexity in the Heart of Software
