آموزش Domain Driven Design - صریح سازی مسائل ذهنی

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

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

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

افراد ساعت ها صرف بحث کردن در مورد چیزهایی می کنند که فکر می کنند متفاوت هستند، اما در واقع یکی هستند. همچنین در مورد چیزی توافق می کنند که درک مشترکی درباره آن ندارند. این توافقات هیچوقت خوب پیش نمی روند. برای حل این مشکل، باید فرضیات را کنار گذاریم. باید چیزهای ضمنی (Implicit) را صریح (Explicit) کنیم.

به نمونه زیر بعنوان یک سیستم مدیریت منابع انسانی واقعی نگاه کنید. در این فرم یک کارمند می تواند درخواست مرخصی کند.

ما در اینجا یک ساختار متداول را می بینیم که توسط یک برنامه نویس ایجاد شده است. همچنین می توانیم تصور کنیم که یک جدول SQL وجود دارد که دیتاهای وارد شده در این فرم را ذخیره سازی می کند. این جدول احتمالا ستون های StartDate، EndDate، HalfDay و Id کارمند را دارد. دقت کنید که یک دکمه Save هم داریم که در فرم هایی شبیه به این بسیار متداول هستند.

با وجود اینکه این فرم کاملا درست به نظر می رسد، بیایید کمی در آن عمیق تر شویم:

• فیلد Start Date دارای ابهام است. آیا اشاره به زمانی دارد که فرم ثبت نام پر شده است یا زمانی است که کارمند بدلیل بیماری سر کار حاظر نشده است؟
• فیلد End Date ابهام بیشتری هم دارد. آیا این تاریخ آخرین روزی است که مرخصی گرفته شده است یا اولین روزی است که کارمند به محل کار باز گشته است؟
• فیلد Half Day می تواند برای هر کدام از دو تاریخ بالا اعمال شود. اما مشخص نشده است که برای کدام روز اتخاذ شده است.
• در نهایت، دکمه Save به ما هیچ نشانه ای از این که بعد از آن چه اتفاقی رخ خواهد داد، نداده است. ممکن است که فقط یک رکورد در دیتابیس افزوده شود و نیاز باشد بریم به کسی بگوئیم که برود آن را نگاه کند. یا ممکن است یک فرایند تایید مرخصی وجود داشته باشد که پس از فشردن Save به سرعت آغاز شود. آیا کارمند نیاز دارد تا بعد از ثبت فرم مرخصی، با ایمیل یا تلفن مدیر خط را در جریان بگذارد؟

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

حالا فرم بالا را با فرم زیر مقایسه کنید:

در این فرم، فیلد ها برای افراد معمولی که نیاز به حل معما یا خوانش راهنما برای پر کردن آن ها ندارند، منطقی تر به نظر می رسد. چیزهایی که در فرم قبل ضمنی بودند، اکنون صریح شده اند. همه چیز، از نام گذاری فیلدها تا دکمه ها (call to action)، معانی بهتری پیدا کردند. همچنین می توانیم تخمین بزنیم پشت این فرم، کدی شبیه به این وجود دارد:

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

جنبه دیگر صریح سازی ضمنی ها، ایجاد مفاهیم دامین است که در کد قابل رویت است. در کد بالا، دستور SendSickLeaveForApproval بیانگر مفهوم دامین دقیقی در کد است.