آموزش طراحی دامنه محور Domain Driven Design و کار با کد های موروثی Legacy

آموزش طراحی دامنه محور Domain Driven Design و کار با کد های موروثی Legacy یکی دیگر از آموزش های گروه آموزشی پرووید می باشد که در این قسمت آن را به شما معرفی می کنیم. این بسته ی آموزشی نیز یکی از دوره های آموزشی دیگر که در حوزه ی فارسی سازی آموزش های انگلیسی تنظیم شده است می باشد. عنوان این بسته ی آموزشی آموزش Domain Driven Design و کار با Legacy Project ها است که با نام اصلی Domain Driven Design: Working with Legacy Projects از شرکت Pluralsight منتشر شده است.

Domain Driven Design چیست؟

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

بنابراین چیزی که ما به دنبال آن هستیم بحث با مشتری درباره نیازهای کسب و کار او است. Domain Driven Design صرفا بر اساس این فرضیات برای ترسیم کردن نیازهای کسب و کار در مدل دامنه است. طراحی دامنه محور همه چیز درباره چگونگی طراحی مدل دامنه شماست. به این معنا که هر کلاس دامنه باید یک رابطه مستقیم با  آنچه که در دامنه کسب و کار است داشته باشد.

Legacy Project چیست؟

Legacy Project (پروژه ی موروثی) و یا Legacy Code (کد موروثی) به سورس کد نرم افزاری گفته می‌شود که دیگر پشتیبانی نمی شود. به عبارت دیگر می‌ توان Legacy Project را سیستم عامل، سخت افزار یا هر سیستم نرم افزاری که دیگر پشتیبانی نمی شود تعریف کرد. اشتباه معمولی که اغلب توسعه دهندگان به آن دچار می‌ شوند این است که Legacy Code را کد می‌ دانند که قدیمی است. گرچه بعضی از توسعه دهندگان نرم افزار به کد موروثی به عنوان کدی که به صورت ضعیف نوشته شده است نگاه می کنند، اما حقیقت این است که کد موروثی کدی است که اصول مهندسی در آن جایی ندارد و دیگر پشتیبانی نمی‌ شود و مرتباً Patch (وصله) می شد.

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

ایجاد Bubble Context برای توسعه مستقل از سیستم قدیمی

در پروژه‌های قدیمی، تغییر مستقیم مدل دامنه ممکن است بخش‌هایی از سیستم را که به رفتارهای قبلی وابسته‌اند تحت تأثیر قرار دهد. آموزش Domain Driven Design: Working with Legacy Projects روشی را بررسی می‌کند که در آن یک Bubble Context با Domain Model جدید ساخته می‌شود تا منطق تازه بتواند در محدوده‌ای مشخص رشد کند. به‌جای بازنویسی یک‌باره کل پروژه، می‌توان بخشی از قابلیت‌ها را با مدل و قواعد مستقل طراحی کرد. این رویکرد به توسعه‌دهنده اجازه می‌دهد تغییرات را محدودتر نگه دارد و وابستگی به ساختارهای قدیمی را به‌تدریج کاهش دهد.

در این مسیر، تقویت Domain Model با Encapsulation مناسب نیز مطرح می‌شود تا قوانین دامنه در ساختار جدید جای مشخصی داشته باشند. این موضوع زمانی اهمیت دارد که مدل قدیمی مسئولیت‌های متعددی را در خود جمع کرده یا تغییرات آن به بخش‌های مختلف سیستم سرایت می‌کند. آموزش همچنین به نکات مربوط به Refactoring و بررسی دوباره‌نویسی پروژه می‌پردازد تا بتوانید درباره میزان تغییر موردنیاز تصمیم آگاهانه‌تری بگیرید. تمرکز اصلی بر ساخت مرزی قابل‌کنترل میان بخش جدید و سیستم موجود است؛ مرزی که امکان توسعه تدریجی را بدون الزام به جایگزینی فوری تمام کدهای قدیمی فراهم می‌کند.

نقش Anti-corruption Layer و مالکیت داده در مهاجرت تدریجی

هنگامی که مدل جدید باید با ساختارها و قراردادهای یک سیستم قدیمی ارتباط برقرار کند، تفاوت مفاهیم و قالب‌های داده می‌تواند طراحی را پیچیده کند. این آموزش ساخت Anti-corruption Layer را بررسی می‌کند؛ لایه‌ای که مسئولیت ترجمه میان مدل جدید و سیستم موجود را بر عهده می‌گیرد تا مفاهیم قدیمی مستقیماً وارد Domain Model تازه نشوند. در ادامه، این لایه به شکل Synchronizing Anti-corruption Layer توسعه داده می‌شود. این موضوع برای سناریوهایی اهمیت دارد که لازم است داده‌های دو بخش هماهنگ بمانند و تغییرات یک سمت در طراحی سمت دیگر اختلال ایجاد نکنند.

مباحث مستقل کردن Bubble با استفاده از Data Storage جداگانه، ذخیره Delivery در پایگاه داده و تصمیم‌گیری درباره Data Ownership نیز به مسئله مرزبندی مسئولیت‌ها مربوط می‌شوند. وقتی یک قابلیت جدید ذخیره‌سازی مستقلی دارد، باید مشخص باشد کدام بخش مالک داده است و ارتباط با سیستم قبلی چگونه انجام می‌شود. آموزش همچنین Orchestration و روش‌های دیگر مدیریت پروژه‌های Legacy را بررسی می‌کند تا تصمیم‌گیری تنها به ایجاد یک لایه ترجمه محدود نماند. این مجموعه موضوعات به توسعه‌دهندگان کمک می‌کند پیچیدگی مهاجرت را به بخش‌های قابل‌مدیریت تقسیم کنند و درباره همگام‌سازی، ذخیره‌سازی و مسئولیت داده‌ها آگاهانه‌تر تصمیم بگیرند.