بررسی Domain Driven Design و رسالت آن در توسعه نرم افزار

[all_time_programmer]

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

در این پست از وبسایت پرووید می خواهیم در رابطه با Domain Driven Design و ادعایی که در رابطه با ساختن نرم افزار ها دارد صحبت کنیم. Domain Driven Design یک استراتژی را برای ساختن نرم افزارهایی که شدیداً رشد خواهند کرد و در طی زمان تکامل پیدا خواهند کرد را فراهم می کند. ادعای دیگر Domain Driven Design این است که نرم افزار شما زیر بار فشار پیچیدگی یا Complexity کمر خم نخواهد کرد. شاید جالب باشد بدانید که بسیاری از اصول Domain Driven Design با باورهای سنتی برنامه نویسی در تضاد است.

[COLOR=#666666][FONT=IRANSans][RIGHT] موضوع نگهداری نرم افزار و یا همان Maintenance از توسعه نرم افزار و یا همان Development بسیار با اهمیت تر است. اگر نگهداری نرم افزار به درستی انجام نشود نتیجه کار نرم افزاری است که همه از آن می ترسند. نرم افزاری که وقتی تغییر کوچکی در آن ایجاد می شود خروجی ش بسیار متفاوت و حتی شوکه کننده است. در چنین شرایطی عملاً Maintenance نرم افزار متوقف می شود و برنامه نویس به سمت برنامه نویسی تدافعی یا همان Defensive Programming سوق پیدا می کند. به عبارت دیگر به جای نگهداری نرم افزار کدهایی را در آن قرار می دهیم که از لحاظ ساختاری یا همان Structural کاملا اشتباه هستند اما تضمین می کنند که کار نرم افزار به درستی انجام شود. ما اینگونه تغییرات بر روی کدی که از قبل موجود است را وصله یا Patch نامگذاری میکنیم. نکته بسیار مهم در رابطه با این Patch ها که غیرساختاری یا Non-Structural هستند این است که با وارد شدن آنها در نرم افزار به پیچیدگی نرم افزار افزوده می شود. نهایتاً نرم افزار به حدی پیچیده می شود که عملا نگهداری آن غیر ممکن است و تصمیم گرفته می شود که نرم افزار به طور کامل کنار گذاشته شود و یا از اول دوباره کد نویسی شود. بگذارید این چرخه یا Cycle را Create-Repair-Abandon-Replace یا همان CRAP بنامیم. طبیعتاً معنی کلمات این سیکل خلق کردن-تعمیر کردن-کنار گذاشتن-جایگزین کردن است. فرض کنید از شما به عنوان برنامه نویس خواسته اند که نرم افزاری را تولید کنید که جایگزین نرم افزار دیگری خواهد شد. نرم افزاری که امکان نگهداری آن وجود ندارد. در واقع شما فاز آخر از سیکل CRAP را انجام می دهید یعنی جایگزینی. در چنین شرایطی احتمال اینکه شما نیز نرم افزاری را تولید کنید که نهایتاً کنار گذاشته شود و امکان نگهداری آن وجود نداشته باشد بسیار بالاست.
منبع: وبسایت پرووید