فصل ۳ — مدیریت پیچیدگی دامنه

همان‌طور که در فصل قبل دیدید، برای موفقیت یک پروژه بسیار مهم است که زبان فراگیری (Ubiquitous Language) ایجاد شود که همهٔ ذی‌نفعان، از مهندسان نرم‌افزار تا خبرگان دامنه، بتوانند با آن ارتباط برقرار کنند. این زبان باید مدل‌های ذهنی خبرگان دامنه از سازوکار درونی و اصول زیربنایی دامنهٔ کسب‌وکار را بازتاب دهد.

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

مدل‌های ناسازگار

به مثال شرکت بازاریابی تلفنی برگردیم. واحد بازاریابی شرکت از طریق تبلیغات آنلاین سرنخ (Lead) تولید می‌کند. واحد فروش نیز وظیفه دارد مشتریان بالقوه را برای خرید محصولات یا خدمات متقاعد کند؛ زنجیره‌ای که در شکل ۳-۱ نمایش داده شده است.

شکل ۳-۱ — نمونهٔ دامنهٔ کسب‌وکار: شرکت بازاریابی تلفنی.

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

واحد بازاریابی

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

واحد فروش

در زمینهٔ واحد فروش، سرنخ موجودیتی بسیار پیچیده‌تر است. این واژه کل چرخهٔ عمر فرایند فروش را نمایندگی می‌کند. سرنخ در اینجا صرفاً یک رویداد نیست، بلکه یک فرایند بلندمدت است.

در مورد چنین شرکت بازاریابی تلفنی‌ای، زبان فراگیر را چگونه باید صورت‌بندی کنیم؟

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

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

بااین‌حال، نمایش چنین مدل واگرایی از دامنهٔ کسب‌وکار در نرم‌افزار دشوارتر است. کد منبع با ابهام خوب کنار نمی‌آید. اگر مدل پیچیدهٔ واحد فروش را وارد فضای بازاریابی کنیم، جایی که نیازی به آن نیست پیچیدگی ایجاد می‌شود؛ جزئیات و رفتارهایی بسیار فراتر از آنچه افراد بازاریابی برای بهینه‌سازی کمپین‌های تبلیغاتی نیاز دارند. در سوی مقابل، اگر مدل فروش را مطابق نگاه بازاریابی ساده کنیم، نیازهای زیردامنهٔ فروش را برآورده نخواهد کرد، زیرا برای مدیریت و بهینه‌سازی فرایند فروش بیش از حد ساده است. در حالت اول راه‌حلی بیش‌مهندسی‌شده (Overengineered) و در حالت دوم راه‌حلی کم‌مهندسی‌شده (Under-engineered) خواهیم داشت.

این بن‌بست را چگونه حل کنیم؟

راه‌حل سنتی برای این مسئله، طراحی یک مدل واحد است که بتوان از آن برای انواع مختلف مسائل استفاده کرد. نتیجهٔ چنین رویکردی مدل‌هایی است که به نمودارهای عظیم موجودیت–رابطه (ERD) تبدیل می‌شوند و گاهی سراسر دیوارهای دفتر را پر می‌کنند. آیا شکل ۳-۲ یک مدل مؤثر است؟

شکل ۳-۲ — نمودار موجودیت–رابطه در مقیاس کل سازمان.

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

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

اکنون به الگوی طراحی دامنه‌محور برای حل چنین سناریوهایی می‌رسیم: الگوی زمینهٔ محدود (Bounded Context).

زمینهٔ محدود چیست؟

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

در مثال قبل، می‌توانیم دو زمینهٔ محدود شناسایی کنیم: بازاریابی و فروش. اصطلاح «سرنخ» در هر دو زمینهٔ محدود وجود دارد، همان‌طور که شکل ۳-۳ نشان می‌دهد. تا زمانی که این اصطلاح در هر زمینهٔ محدود فقط یک معنا داشته باشد، هر زبان فراگیر ریزدانه سازگار است و با مدل ذهنی خبرگان دامنهٔ همان زمینه مطابقت دارد.

شکل ۳-۳ — حل ناسازگاری‌های زبان فراگیر با تقسیم آن به زمینه‌های محدود.

به یک معنا، تعارض‌های واژگانی و زمینه‌های ضمنی جزء ذاتی هر کسب‌وکار با اندازهٔ قابل توجه هستند. با الگوی زمینهٔ محدود، این زمینه‌ها به بخش صریح و جدایی‌ناپذیر مدل دامنهٔ کسب‌وکار تبدیل می‌شوند.

مرزهای مدل

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

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

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

تعریف دقیق‌تر زبان فراگیر

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

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

دامنهٔ یک زمینهٔ محدود

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

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

شکل ۳-۴ — زمینه‌های محدود کوچک‌تر.

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

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

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

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

پس مدل‌ها را مفید نگه دارید و اندازهٔ زمینه‌های محدود را با نیازهای کسب‌وکار و محدودیت‌های سازمانی هم‌راستا کنید. نکته‌ای که باید از آن پرهیز کرد شکستن یک قابلیت منسجم به چند زمینهٔ محدود است. چنین تقسیمی توانایی تکامل مستقل هر زمینه را کاهش می‌دهد، زیرا همان نیازها و تغییرات کسب‌وکار هم‌زمان چند زمینه را تحت تأثیر قرار می‌دهند و استقرار هم‌زمان تغییرات را ضروری می‌کنند. برای پرهیز از چنین تجزیهٔ نامؤثری، از قاعدهٔ فصل ۱ برای یافتن زیردامنه‌ها استفاده کنید: مجموعه‌های منسجم موارد کاربرد (Use Cases) را که روی دادهٔ مشترک کار می‌کنند شناسایی کنید و آنها را میان چند زمینهٔ محدود تقسیم نکنید.

در فصل‌های ۸ و ۱۰ دوباره به موضوع بهینه‌سازی مستمر مرزهای زمینه‌های محدود خواهیم پرداخت.

زمینه‌های محدود در برابر زیردامنه‌ها

در فصل ۲ دیدیم که دامنهٔ کسب‌وکار از چند زیردامنه تشکیل می‌شود. در این فصل نیز تجزیهٔ دامنهٔ کسب‌وکار به مجموعه‌ای از دامنه‌های مسئلهٔ ریزدانه، یا زمینه‌های محدود، را بررسی کردیم. در نگاه اول ممکن است این دو روش تجزیه زائد به نظر برسند، اما چنین نیست. بیایید ببینیم چرا به هر دو نوع مرز نیاز داریم.

زیردامنه‌ها

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

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

زمینه‌های محدود

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

تعامل زیردامنه‌ها و زمینه‌های محدود

از نظر نظری ــ هرچند در عمل غالباً نامناسب ــ یک مدل واحد می‌تواند کل دامنهٔ کسب‌وکار را پوشش دهد. این راهبرد ممکن است برای یک سیستم کوچک کار کند، مانند شکل ۳-۵.

شکل ۳-۵ — زمینهٔ محدود یکپارچه و تک‌مدلی.

وقتی مدل‌های متعارض پدیدار شوند، می‌توانیم از مدل‌های ذهنی خبرگان دامنه پیروی کنیم و سیستم را به چند زمینهٔ محدود تقسیم کنیم، همان‌طور که در شکل ۳-۶ آمده است.

شکل ۳-۶ — زمینه‌های محدود هدایت‌شده توسط سازگاری زبان فراگیر.

اگر مدل‌ها همچنان بزرگ و نگه‌داری آنها دشوار باشد، می‌توانیم آنها را به زمینه‌های محدود کوچک‌تری تجزیه کنیم؛ برای مثال، برای هر زیردامنه یک زمینهٔ محدود بسازیم، همانند شکل ۳-۷.

شکل ۳-۷ — زمینه‌های محدود هم‌راستا با مرزهای زیردامنه‌ها.

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

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

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

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

مرزها

همان‌طور که Ruth Malan می‌گوید، طراحی معماری ذاتاً دربارهٔ مرزهاست:

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

Ruth Malan

الگوی زمینهٔ محدود ابزار DDD برای تعریف مرزهای فیزیکی و مرزهای مالکیت است.

مرزهای فیزیکی

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

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

همان‌طور که قبلاً گفتیم، یک زمینهٔ محدود می‌تواند چند زیردامنه را دربر گیرد. در چنین حالتی، زمینهٔ محدود یک مرز فیزیکی است و هر زیردامنه درون آن یک مرز منطقی. مرزهای منطقی در زبان‌های برنامه‌نویسی مختلف نام‌های متفاوت دارند: فضای نام (Namespace)، ماژول (Module) یا بسته (Package).

مرزهای مالکیت

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

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

مهم است بدانیم رابطهٔ تیم‌ها و زمینه‌های محدود یک‌جهته است: هر زمینهٔ محدود فقط باید یک مالک تیمی داشته باشد، اما یک تیم می‌تواند مالک چند زمینهٔ محدود باشد، همان‌طور که شکل ۳-۸ نشان می‌دهد.

شکل ۳-۸ — تیم ۱ روی زمینه‌های محدود Marketing و Optimization کار می‌کند و تیم ۲ مالک زمینهٔ Sales است.

زمینه‌های محدود در دنیای واقعی

در یکی از کلاس‌های طراحی دامنه‌محور من، یکی از شرکت‌کنندگان گفت: «شما گفتید DDD دربارهٔ هم‌راستا کردن طراحی نرم‌افزار با دامنه‌های کسب‌وکار است. اما زمینه‌های محدود در دنیای واقعی کجا هستند؟ در دامنه‌های کسب‌وکار چیزی به نام زمینهٔ محدود وجود ندارد.»

درست است که زمینه‌های محدود به اندازهٔ دامنه‌ها و زیردامنه‌های کسب‌وکار آشکار نیستند، اما وجود دارند؛ همان‌طور که مدل‌های ذهنی خبرگان دامنه وجود دارند. کافی است نسبت به شیوه‌ای که خبرگان دربارهٔ موجودیت‌ها و فرایندهای مختلف فکر می‌کنند آگاه باشید.

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

دامنه‌های معنایی

می‌توان گفت زمینه‌های محدود DDD بر مفهوم واژه‌شناختی «دامنهٔ معنایی (Semantic Domain)» تکیه دارند. دامنهٔ معنایی حوزه‌ای از معنا و واژه‌هایی است که برای صحبت دربارهٔ آن استفاده می‌شوند. برای مثال واژه‌های monitor، port و processor در دامنه‌های معنایی مهندسی نرم‌افزار و سخت‌افزار معانی متفاوتی دارند.

نمونه‌ای جالب‌تر، معنای واژهٔ «گوجه‌فرنگی» است.

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

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

بنابراین در زمینهٔ محدود گیاه‌شناسی، گوجه‌فرنگی میوه است، اما در زمینهٔ محدود آشپزی، سبزی محسوب می‌شود. و داستان به همین‌جا ختم نمی‌شود.

در سال ۱۸۸۳ ایالات متحده مالیات ۱۰ درصدی بر سبزیجات وارداتی وضع کرد، اما میوه‌ها مشمول این مالیات نبودند. تعریف گیاه‌شناختی گوجه‌فرنگی به‌عنوان میوه امکان واردات آن بدون پرداخت مالیات را فراهم می‌کرد. برای بستن این راه گریز، دیوان عالی ایالات متحده در سال ۱۸۹۳ تصمیم گرفت گوجه‌فرنگی را به‌عنوان سبزی طبقه‌بندی کند. پس در زمینهٔ محدود مالیات، گوجه‌فرنگی سبزی است.

افزون بر این، همان‌طور که دوست نویسنده Romeu Moura می‌گوید، در زمینهٔ محدود اجرای تئاتری، گوجه‌فرنگی یک «سازوکار بازخورد» است.

علم

به تعبیر مورخ Yuval Noah Harari، «دانشمندان عموماً توافق دارند که هیچ نظریه‌ای صددرصد درست نیست. بنابراین آزمون واقعی دانش، حقیقت نیست، بلکه سودمندی است.» به بیان دیگر، هیچ نظریهٔ علمی در همهٔ موارد درست نیست؛ نظریه‌های متفاوت در زمینه‌های متفاوت مفیدند.

این مفهوم را می‌توان با مدل‌های متفاوت گرانش ارائه‌شده توسط Sir Isaac Newton و Albert Einstein نشان داد. در قوانین حرکت نیوتن، فضا و زمان مطلق‌اند؛ صحنه‌ای هستند که حرکت اجسام در آن رخ می‌دهد. در نظریهٔ نسبیت اینشتین، فضا و زمان دیگر مطلق نیستند و برای ناظران مختلف متفاوت‌اند.

هرچند این دو مدل می‌توانند متناقض به نظر برسند، هر دو در زمینهٔ محدود مناسب خود مفید هستند.

خرید یک یخچال

در پایان، نمونه‌ای زمینی‌تر از زمینه‌های محدود در زندگی واقعی را ببینیم. در شکل ۳-۹ چه می‌بینید؟

شکل ۳-۹ — یک تکه مقوا.

آیا این فقط یک تکه مقواست؟ خیر، یک مدل است؛ مدلی از یخچال Siemens KG86NAI31L. اگر مشخصات آن یخچال را ببینید ممکن است بگویید این مقوا اصلاً شبیه یخچال نیست: در ندارد و حتی رنگ آن هم متفاوت است. این حرف درست است، اما ربطی به مسئله ندارد. همان‌طور که گفتیم، مدل قرار نیست کپی موجودیت واقعی باشد؛ باید هدفی داشته باشد، یعنی مسئله‌ای را حل کند. بنابراین پرسش درست این است: این مدل مقوایی چه مسئله‌ای را حل می‌کند؟

در آپارتمان نویسنده، ورودی آشپزخانه استاندارد نیست. مقوا دقیقاً به اندازهٔ عرض و عمق یخچال بریده شده است. مسئله‌ای که حل می‌کند این است که بررسی شود آیا یخچال از درِ آشپزخانه عبور می‌کند یا نه؛ همان‌طور که در شکل ۳-۱۰ دیده می‌شود.

شکل ۳-۱۰ — مدل مقوایی در ورودی آشپزخانه.

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

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

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

چند روز پس از انتشار این داستان در Twitter، شخصی پاسخ داد که به‌جای درگیر شدن با مقوا می‌شد از تلفن همراه دارای اسکنر LiDAR و یک برنامهٔ واقعیت افزوده (AR) استفاده کرد. بیایید این پیشنهاد را از دید DDD تحلیل کنیم.

نویسندهٔ آن نظر می‌گوید این مسئله‌ای است که دیگران پیش‌تر حل کرده‌اند و راه‌حل آن نیز آماده است. ناگفته پیداست که هم فناوری اسکن و هم برنامهٔ AR پیچیده‌اند. در زبان DDD، این ویژگی‌ها مسئلهٔ «بررسی عبور یخچال از در» را به یک زیردامنهٔ عمومی (Generic Subdomain) تبدیل می‌کنند.

جمع‌بندی

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

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

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

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

تمرین‌ها

1. تفاوت زیردامنه‌ها و زمینه‌های محدود چیست؟
   1. زیردامنه‌ها طراحی می‌شوند و زمینه‌های محدود کشف می‌شوند.
   2. زمینه‌های محدود طراحی می‌شوند و زیردامنه‌ها کشف می‌شوند.
   3. زمینه‌های محدود و زیردامنه‌ها اساساً یکسان‌اند.
   4. هیچ‌کدام از موارد بالا درست نیست.
2. زمینهٔ محدود، مرز کدام مورد است؟
   1. یک مدل
   2. یک چرخهٔ عمر
   3. مالکیت
   4. همهٔ موارد بالا
3. کدام عبارت دربارهٔ اندازهٔ یک زمینهٔ محدود درست است؟
   1. هرچه زمینهٔ محدود کوچک‌تر باشد، سیستم انعطاف‌پذیرتر است.
   2. زمینه‌های محدود همیشه باید با مرز زیردامنه‌ها هم‌راستا باشند.
   3. هرچه زمینهٔ محدود وسیع‌تر باشد، بهتر است.
   4. بستگی دارد.
4. کدام عبارت دربارهٔ مالکیت تیمی یک زمینهٔ محدود درست است؟
   1. چند تیم می‌توانند روی یک زمینهٔ محدود کار کنند.
   2. یک تیم می‌تواند مالک چند زمینهٔ محدود باشد.
   3. هر زمینهٔ محدود فقط می‌تواند متعلق به یک تیم باشد.
   4. گزینه‌های B و C درست‌اند.
5. مثال شرکت WolfDesk در پیشگفتار را مرور کنید و قابلیت‌هایی از سیستم را شناسایی کنید که ممکن است به مدل‌های متفاوتی از یک تیکت پشتیبانی نیاز داشته باشند.
6. علاوه بر مثال‌های این فصل، چند نمونه از زمینه‌های محدود در زندگی واقعی پیدا کنید.

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

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