بعید است یک برنامه نویس Back-end باشید و طراحی دامنه محور (DDD) به گوشتان نخورده باشد. البته به نظر میرسد نقش DDD در میان برنامه نویسان به عنوان یک Buzzword خیلی پر رنگ تر از نقش آن به عنوان یک رویکرد عملی در طراحی نرم افزار باشد :)
در هر صورت اینکه همه در مورد آن صحبت میکنند، دلیل خوبی برای یادگیری و بکارگیری آن نیست(البته کلا دلیل خوبی برای یادگیری هیچ چیزی نیست).
شخصا همیشه پیش از اینکه یک روش یا ابزار جدید را یاد بگیرم باید درک کنم بدون آن قبلا چطور کارم را انجام می دادم، چه مشکلی با روش قبلی دارم و روش جدید چطور این مشکل را حل خواهد کرد.
در مورد DDD همینگونه است. واقعیت آن است که DDD جادو نمیکند. فقط جایگزین رویکرد پیشین ما در طراحی سه لایه است. رویکردی که تنها از زاویه ذخیره و بازیابی اطلاعات به نرم افزار نگاه میکند. در این رویکرد منطق برنامه صرفا ترکیبی از عملیات های CRUD است.
در پایان این نوشتار میخواهیم بدانیم DDD چه مشکلی را قرار است حل کند و به عبارت دیگر استفاده آن در چه نوع پروژه هایی معقول و منطقی است؟
DDD می خواهد محوریت برنامه را از ذخیره و بازیابی اطلاعات به لایه ای به نام دامنه تغییر دهد. این نگرش در توسعه نرم افزار هزینه و فایده خود را دارد و قرار نیست به طرز جادوئی همه مشکلات ما را حل کند.
برای درک اینکه DDD دقیقا چه مشکلی را حل میکند باید نگاهی به معماری سه لایه بیندازیم.
رویکرد سنتی ما در طراحی نرم افزار چگونه است
ما معمولا به عنوان برنامه نویس هنگامی که نیازمندی های نرم افزار را از کارشناسان آن دامنه (مثلا دامنه سیستم انبارداری) دریافت می کنیم در ذهن خودمان مستقیما آنها را به ترکیبی از عملیات های ذخیره و بازیابی تبدیل میکنیم. و برنامه ما معمولا ترکیبی از این عملیات های ذخیره و بازیابی است که اصطلاحا CRUD نامیده میشود.
تا زمانی که منطق نرم افزار ما در ذخیره و بازیابی اطلاعات دریافتی با کمترین تغییر ممکن در آن خلاصه میشود، این روش بسیار ساده و کارآمد عمل میکند.
اما شرایطی را تصور کنید که مثلا تغییر در یک فیلد در یک جدول باعث تغییر چندین فیلد دیگر در جداول دیگر شود و به دنبال آن یک وب سرویس هم از یک برنامه دیگر فراخوانی شود.
مثلا یک سیستم انبارداری را در نظر بگیرید. با خروج یک کالا از انبار باید چندین رکورد اطلاعاتی علاوه بر خود record کالا تغییر کند.
میدانیم که محل قراردادن اینطور logic ها نه در لایه UI است نه در لایه Data Access. تنها گزینه، قرار دادن آنها در لایه Business Logic است. اما با افزایش تعداد این نوع نیازمندی ها، اتفاقی که رخ می دهد این است که منطق برنامه ما بصورت پراکنده و شلخته ای در برنامه درقالب عملیات های ذخیره و بازیابی پخش شده است. عملیات هایی که هیچگونه معنایی خارج از دنیای برنامه نویسی ندارند. این موجب میشود که
1. خوانایی کد پائین بیاید
2. کد های تکراری افزایش پیدا کند
3. درک عملکرد برنامه بسیار پیچیده شود
4. اشکال زدایی و نگهداری برنامه هزینه بر شود
در چنین شرایطی راه حل این است که منطق اصلی برنامه تا حد ممکن در یک نقطه متمرکز شود. متمرکز کردن Business Logic ها تا حد ممکن، مسئله ای است که DDD قرار است آن را حل کند. ( البته من از نگاه یک توسعه دهنده نرم افزار به DDD نگاه کرده ام و نه یک مدیر پروژه یا هر نقش سازمانی دیگری).
راهکار DDD برای متمرکز کردن منطق برنامه چیست
DDD بطور کلی تاکید می کند منطق برنامه را تا حد ممکن بجای قرار دادن در توابع لایه Business Logic در دامنه ای از مدل ها متمرکز کنید(اینکه چطور لایه دامنه را طراحی کنیم و چطور ارتباط آن با لایه های دیگر را برقرار کنیم موضوعی است که باید جداگانه به آن پرداخته شود)
مدل ها از طریق امکانات Object Oriented به ویژه با رعایت Encapsulation همیشه خود را در وضعیت معتبر حفظ خواهند کرد، فارغ از اینکه این تغییرات از چه نقطه ای از برنامه نشأت گرفته باشد. تغییر در یک مدل میتواند باعث دنباله از تغییرات در مدل های دیگر دامنه هم بشود. اما یکپارچگی و صحت وضعیت مدل ها حفظ خواهد شد.
در طراحی این دامنه از مدل ها دغدغه های شیوه ذخیره و بازیابی اطلاعات و چگونگی تعامل با کاربر مدنظر نیست و تاکید بيشتر بر پیاده سازی نیازمندی های دامنه کسب کار است.
لایه دامنه اغلب برای عملیات های Create, Update, Delete (که تغییر دهنده وضعیت سیستم هستند) کارکرد خود را نشان میدهد و معمولا در زمینه Read ارزش افزوده خاصی ارائه نمی دهد.
یک نکته مهم دیگر درباره لایه دامنه وجود دارد. و آن این است که تمامی مدل ها و شیوه ارتباط آنها با هم به یک زبان قابل فهم و غیر فنی بیان میشود. بنابراین برای کسانی که با آن درگیر هستند، اعم از برنامه نویس ، تحلیلگر و کارشناسان آن دامنه کاملا قابل فهم است. به زبان ساده تر نام مدل(یا همان کلاس) ، behavior ها ، event ها و property های آن کاملا برای کارشناسان دامنه معنادار است.
این موضوع کمک می کند که همه این افراد فارغ از مسائل فنی مربوط به خود نگاه مشترکی نسبت به هسته مرکزی نرم افزار داشته باشند. برخلاف روش قبل که هیچکس بجز برنامه نویس از لایه Business Logic چیزی نمی فهمید. این شفافیت در منطق برنامه قدرت حل مسئله را هم به طرز مطلوبی افزایش میدهد.
بنابر این یک لایه تحت عنوان Domain که داخلی ترین لایه برنامه خواهد بود به برنامه ما اضافه خواهد شد.
این لایه قلب نرم افزار ما خواهد بود. و هرگونه تغییری در منطق برنامه از انجا شروع میشود. مابقی قسمت های برنامه مانند بخش رابط کاربری(UI) یا ذخیره و بازیابی اطلاعات (Repository) در خدمت دامنه قرار دارند . بخش رابط کاربری درخواست های کاربر را به دامنه منتقل می کند و بخش ذخیره و بازیابی وظیفه Persistency دامنه را برعهده دارد.
