نکاتی درباره Domain driven design

از زمانی که با Domain driven design آشنا شده ام هر روز با مطالب جدیدتری در این حوزه آشنا شده و تجارب بیشتری کسب می کنم. آشنایی با یک مفهوم بزرگ مثل Domain driven design صرفا خواندن کتاب نیست و استفاده از آن به تجربه نیاز دارد . با افراد زیادی در این خصوص صحبت کرده ام ، از افراد تازه کار در حوزه توسعه نرم افزار گرفته تا کسانی که چندین سال در این زمینه سابقه و تجربه دارند. با این حال هنوز در بین صحبت های همه این افراد برداشت های نادرست و تعابیر غلطی وجود دارد که سبب اشتباهات رایجی می شود و شخصا نیز بارها درگیر آنها شده ام ، که نشان از عدم درک درست از Domain driven design در جامعه توسعه دهندگان نرم افزار است.بنابراین سعی کردم تا چند نکته مهم و کاربردی را در خصوص Domain driven design جمع آوری کرده و در غالب این مطلب بازگو نمایم . در Domain driven design مهمترین مساله شناخت دقیق کسب و کار و دامنه آن است ، یعنی همان چیزی که پروژه برای تحقق آن شروع شده و پیش می رود .1- طراحی مبتنی بر دامنه (DDD) یک معماری نرم افزار نیست.2- طراحی مبتنی بر دامنه یک رویکرد و مجموعه ای از مفاهیم است که در تمام فاز های چرخه توسعه کاربرد دارد مانند TDD و EDD .3- برای مسائل و پروژه های کوچک و ساده نیازی به استفاده از آن نیست. (یا حداقل نیازی به استفاده کامل و جامع از آن نیست)4- از DDD برای تحلیل و پیشبرد پروژه های بزرگ و پیچیده استفاده می شود.5- هر کدی که لایه Domain model را جدا کرده بود لزوما DDD را رعایت نکرده ، همانطور که اگر برای یک پروژه تست نوشته شده باشد لزوما TDD را رعایت نکرده .6- استفاده از معماری های Domain centric مثل Onion و Clean لزوما به معنای این نیست که ما پروژه را با رویکرد DDD پیش می بریم.7- در DDD اصل موضوع ، روش تحلیل و برخورد با صورت مسئله و روش شناسایی نیازمندی ها و دانش دامنه کسب و کار و روش های استراتژیک آن است ، نه روش های پیاده سازی .8- در DDD ، درخصوص معماری مورد استفاده در پیاده سازی اجباری نیست و فقط پیشنهاداتی برای آن دارد.9- رویکرد DDD را میتوان با معماری Onion یا Clean یا هر معماری Domain centric دیگر پیاده سازی کرد.10- مهمترین اصل DDD در مرحله پیاده سازی ، پیاده سازی با زبان دامنه و کسب و کار و فارغ از تکنولوژی بودن دامنه پروژه است.11- در DDD برای نحوه صحبت کردن با صاحب محصول هم روش و استراتژی وجود دارد.12- وقتی کد های یک پروژه که به روش DDD پیاده سازی شده را می خوانید باید بتوانید تشخیص دهید که این کدها مربوط به چه کسب و کاری است و به راحتی از کد ، به کسب و کار پشت آن پی ببرید.(کد باید با آدم حرف بزنه)13- تشخیص و جداسازی درست Aggregate ها در DDD کمک میکند تا در آینده خیلی راحت تر بتوان پروژه را توسعه داد ، scale out کرد یا هر کدام از Aggregate ها را به طور مستقل توسعه داد.14- استفاده از DDD کمک میکند تا نیاز کمتری به نوشتن داکیومنت برای کدها ، ای پی آی ها و غیره داشته باشیم. مستندات کسب و کار و فرآیند ، مهم تر هستند.15- برای DDD مهم نیست که شما از معماری Clean , Onion , N-Layer یا غیره استفاده میکنید ، اگرچه پیاده سازی آن با معماری Clean در حال حاظر اوج هنرمندی در دنیای توسعه نرم افزار است.15- زمان ، هزینه ، توانایی تیم توسعه و امکانات در اختیار را ، باید برای انتخاب رویکرد DDD در نظر گرفت.16- اگر پروژه را با رویکرد Domain driven design پیش می بریم ، باید Context map کاملی از کسب و کار و پروژه داشته باشیم ، که همه اعضای تیم توسعه ، کنترل پروژه ، مدیریت و صاحب محصول از آن اطلاع داشته باشند.17- بدون شناخت و تحلیل درست کسب و کار و دانش دامنه ، ادامه راه DDD و ورود به مرحله پیاده سازی صحیح نیست.18- اگر عضو جدیدی وارد تیم توسعه می شود ابتدا باید با کسب و کار و دامنه پروژه آشنا شود تا بداند که برای چه چیزی کار میکند و چگونه ارزش آفرینی کند.