زبان مشترک (Ubiquitous Language) چیست؟

در پروژه‌های نرم‌افزاری سنتی، معمولاً شکاف بزرگی بین «متخصصان کسب‌وکار» (Domain Experts) و «توسعه‌دهندگان» وجود دارد. بیزنس‌من‌ها با اصطلاحات خاص خود (مانند "تسویه حساب"، "اعتبار مشتری"، "تسهیلات") صحبت می‌کنند و برنامه‌نویسان با اصطلاحات فنی (مانند "Table"، "API"، "Boolean"، "ID").

این تفاوت زبان باعث می‌شود که در هنگام تبدیل نیازمندی‌ها به کد، بخش زیادی از جزئیات و مفاهیم در «ترجمه» گم شوند.

Ubiquitous Language راهکاری است برای حل این مشکل. این زبان، زبانی است که:

• توسط کل تیم (برنامه‌نویسان، مدیران محصول، کارشناسان دامنه) پذیرفته شده است.

• در کد، نمودارها، جلسات و مستندات به صورت یکسان استفاده می‌شود.

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

جایگاه زبان مشترک در معماری تمیز

معماری تمیز که توسط رابرت سی. مارتین (Uncle Bob) معرفی شد، بر جداسازی دغدغه‌ها (Separation of Concerns) و استقلال کد از فریمورک‌ها تاکید دارد. لایه‌های اصلی آن عبارتند از:

1. Entities (موجودیت‌ها)

2. Use Cases (موارد استفاده/اینتراکتورها)

3. Interface Adapters (مبدل‌ها)

4. Frameworks & Drivers

در معماری تمیز، زبان مشترک دقیقاً در مرکز دایره (لایه Entities و Use Cases) تعریف می‌شود و به سمت بیرون نشت می‌کند.

الف) لایه موجودیت‌ها (Entities): اسم‌های زبان مشترک

موجودیت‌ها حاوی قوانین بیزنس هستند که با تغییرات ظاهری یا دیتابیس تغییر نمی‌کنند. نام‌گذاری کلاس‌ها، متدها و فیلدها در این لایه باید دقیقاً بر اساس Ubiquitous Language باشد.

• اگر متخصص دامنه می‌گوید «مشتری می‌تواند سبد خرید خود را نهایی کند»، در کد ما نباید متدی به نام updateStatus(4) داشته باشیم؛ بلکه باید متدی به نام finalizeCheckout() در موجودیت Cart وجود داشته باشد.

ب) لایه موارد استفاده (Use Cases): فعل‌های زبان مشترک

این لایه جریان داده را به سمت موجودیت‌ها و از آن‌ها هدایت می‌کند. Use Caseها در واقع سناریوهای دنیای واقعی هستند.

• نام کلاس‌های این لایه باید جملات خبری در زبان مشترک باشند. مانند: PlaceOrder, CancelSubscription, ReconcileAccount.

چرا در معماری تمیز به این زبان نیاز داریم؟

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

۱. کاهش هزینه ترجمه ذهنی

• وقتی کدی را می‌خوانید که از زبان مشترک استفاده می‌کند، نیازی ندارید در ذهن خود ترجمه کنید که «فیلد is_active در دیتابیس یعنی اینکه آیا کاربر اجازه ورود دارد یا خیر». نام متد یا فیلد مستقیماً هدف بیزنس را بیان می‌کند: canLogin().

۲. پایداری در برابر تغییرات

• معماری تمیز به دنبال این است که منطق بیزنس (Core) تحت تأثیر تغییرات تکنولوژی (مثل تغییر از SQL به NoSQL) قرار نگیرد. زبان مشترک باعث می‌شود که منطق بیزنس بر اساس مفاهیم بیزنس شکل بگیرد، نه بر اساس ساختار دیتابیس.

۳. کشف مفاهیم پنهان

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

پیاده‌سازی عملی: از کلام تا کد

بیایید با یک مثال ببینیم چگونه Ubiquitous Language در کدِ یک سیستم بانکی که از معماری تمیز پیروی می‌کند، ظاهر می‌شود.

گفتگوی بیزنس:

"وقتی یک مشتری می‌خواهد انتقال وجه انجام دهد، باید بررسی کنیم که مانده قابل برداشت او کافی باشد."

پیاده‌سازی غلط (بدون زبان مشترک):

public void Process(int id, double amt) {
    var u = repo.GetById(id);
    if (u.Balance > amt) {
        u.Balance -= amt;
        repo.Save(u);
    }
}

در اینجا مشخص نیست u چیست؟ Process چه کاری انجام می‌دهد؟ آیا Balance همان مانده قابل برداشت است؟

پیاده‌سازی درست (با زبان مشترک در معماری تمیز):

public class TransferFundsUseCase {
    public void Execute(AccountId senderId, Amount amount) {
        var sender = accountRepository.Find(senderId);
        
        if (sender.HasSufficientWithdrawableBalance(amount)) {
            sender.Debit(amount);
            accountRepository.Update(sender);
        } else {
            throw new InsufficientFundsException();
        }
    }
}

در نسخه دوم، کد دقیقاً همان چیزی را می‌گوید که متخصص بیزنس بیان کرده است. کلمات TransferFunds, WithdrawableBalance و Debit بخشی از زبان مشترک هستند.

چالش‌ها و مفهوم Bounded Context

یکی از اشتباهات بزرگ در پیاده‌سازی زبان مشترک، تلاش برای ایجاد یک زبان واحد برای کل یک سازمان بزرگ است. در معماری تمیز و DDD، ما از مفهومی به نام Bounded Context (محدوده محصور) استفاده می‌کنیم.

ممکن است کلمه «محصول» (Product) در بخش «فروش» معنای متفاوتی نسبت به بخش «انبارداری» داشته باشد:

• در فروش: محصول دارای قیمت، تخفیف و عکس است.

• در انبارداری: محصول دارای وزن، ابعاد و شماره قفسه است.

معماری تمیز اجازه می‌دهد که هر کدام از این بخش‌ها، Core (موجودیت‌ها و یوزکیس‌های) خودشان را داشته باشند و زبان مشترک مخصوص به خود را در آن محدوده تعریف کنند.

نتیجه‌گیری و گام‌های بعدی

Ubiquitous Language در معماری تمیز، تنها یک لیست از لغات نیست؛ بلکه ابزاری است برای اطمینان از اینکه کدی که می‌نویسیم، واقعاً در حال حل مسئله‌ی بیزنس است، نه صرفاً جابجا کردن داده‌ها. وقتی شما از نام‌گذاری‌های دقیق و همسو با بیزنس استفاده می‌کنید، کد شما به "مستنداتی زنده" تبدیل می‌شود.

خلاصه نکات کلیدی:

• زبان مشترک باید در لایه‌های درونی (Entities & Use Cases) معماری تمیز حاکم باشد.

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

• این زبان باید در تست‌های واحد (Unit Tests) نیز به کار گرفته شود تا سناریوها قابل فهم باشند.