آموزش Domain Driven Design. زبان مشترک و فراگیر

اتفاقی نیست که اریک ایوانز نویسنده اصلی کتاب DDD، آدرس سایتش را domainlanguage.com انتخاب کرده است. مفاهیم پایه ای DDD مانند زبان فراگیر (Ubiquitous Language) و مرزبندی زمینه ها (Bounded Context) بر اساس ایده زبان ایجاد شده اند. ممکن است این مساله برای برنامه نویسان تازه کار عجیب به نظر برسد. چرا که از نگاه آنها، تنها زبان با اهمیت، زبان برنامه نویسی است. ما فرض می کنیم که ترجمه زبان انسان ها به یک زبان برنامه نویسی، عصاره کار ماست. در حالیکه تا حدودی این مطلب صحیح است اما با بخش حیاتی کار روزانه ما بعنوان توسعه دهندگان نرم افزار فاصله دارد.

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

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

زبان دامین

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

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

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

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

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

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

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

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

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

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

دامین نمونه یک اپلیکیشن

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

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

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

در بخش های بعدی، در جزئیات این دامین بیشتر غرق می شویم و به آهستگی و با درک مفاهیم و دانش های جدید نسبت به ساخت و توسعه آن اقدام می کنیم.