چرا Domain Driven Design انتخاب خوبی برای ساخت مدل است؟
Rohalah Delpak
قبلا توضیح داده بودم که طراحی متاثر از حوزه ی کاری (Domain Driven Design) منجر به کاهش، درک و نهایتا قابل مدیریت کردن پیچیدگیهای موجود در حوزه عملیاتی نرم افزار (Domain) می شود. توجه کنیم که تحیلی و مدلسازی، فعالیتهای رایج در حوزه هایی مانند حمل و نقل، اکتشافات، هوا فضا، شبکه های اجتماعی و ... می تواند بسیار دشوار باشد. برای مثال فرض کنید که می خواهید به مدلسازی نرم افزاری بپردازید که هدف تولید آن پیش بینی وضع آب و هوا است. این حوزه کاری (پیش بینی وضع آب و هوا) بویژه همواره یکی از حوزه (Domain) های پیچیده برای طراحان مدل محسوب می شود. DDD روشی است که با بکار گیری آن می توانید این پیچیدگیها را بسیار کاهش دهید. توسعه سیستمهای پیچیده بدون رعایت قواعدی همه فهم، نهایتا نرم افزار را به مجموعه ای از کدهای غیر خوانا و دیرفهم تبدیل می کند که احتمالا نسل بعدی توسعه دهندگانش را تشویق به بازنویسی آن خواهد کرد.
DDD در واقع روشی است برای دقیق تر فکر کردن در
مورد نحوه ارتباط و تعامل اجزای مدل با یکدیگر. این سبک طراحی (DDD) به تولید مدلی از اشیاء می انجامد که نهایتا تصویری قابل درک (Model) از مسائل مطرح در حوزه ی کاری ارائه می دهند. این مدل ارزشمند
است وقتی که:
1 – نمایی آشکار و در عین حال در نهایت سادگی و وضوح از همه ی مفاهیمی باشد که در حوزه عملیاتی نرم افزار(Domain) وجود دارد.
2- به تناسب درک کاملتری که از حوزه کاری کسب می شود بتوان این مدل را بهبود و توسعه داد(Refactoring).
در DDD کوشش می شود که با برقراری ارتباطی منطقی بین اشیاء، و رعایت سطوحی از انتزاع یک مشکل بزرگتر را به مشکلات کوچکتر شکست و سپس به حل این مشکلات کوچکتر پرداخت.
توجه کنیم که DDD به چگونگی سازماندهی اشیاء توجه ویژه ای دارد ولی DDD چیزی درباره برنامه نویسی شی گرا نیست. DDD متدولوژیی است که با بهره گیری از مفاهیم شی گرایی و مجموعه ای از تجارب ممتاز توسعه نرم افزار (Best Practice) پیچیدگیها را و قابلیت توسعه و نگهداری نرم افزار را بهبود می دهد.
ایده مستتر در DDD ساده است. اگر در حوزه کاری مفهوم (Concept) ارزشمندی وجود دارد باید بتوان آن را به وضوح در مدل مشاهده کرد. برای مثال صحیح نیست که یک شرط ارزشمند حوزه کسب و کار را با مجموعه ی سخت فهمی از If / Else ها، در مدل نشان داد. این شرط مهم را می توان با Specification pattern پیاده سازی کرد تا تصویری خوانا تر از Domain در مدل بوجود بیاید.
مدلی که دستیبابی به آن در DDD دنبال می شود مدلی است سر راست و گویا با در نظر گرفتن همه جوانب و قواعد حوزه ی عمل نرم افزار. در این مدل مطلوب و ایده آل به مسائل ذخیره سازی (persistence) پرداخته نمی شود. (رعایت اصل PI). این مدل نگران چگونگی نمایش داده ها در واسط کاربری نیست. این مدل نگران داستانهای Ajax نیست. این مدل یک مدل Pure است که دوست داریم حتی المقدور POCO باشد. این مدلی است برای بیان قواعد و منطق موجود در حوزه عمل نرم افزار. این قواعد همیشه تغییر می کنند و مدلی که از آموزه های DDD الهام گرفته باشد، راحت تر پذیرای این تغییرات خواهد بود. به همین دلیل DDD با روشهای توسعه به سبک اجایل نیز قرابت بیشتری دارد.
--
My profile in Linkedin