فرشید عزیزی
فرشید عزیزی
خواندن ۸ دقیقه·۳ سال پیش

لایه Domain در طراحی دامنه گرا DDD

دامنه چیست؟

برای تعریف طراحی مبتنی بر دامنه، ابتدا باید منظور خود از دامنه را در این زمینه مشخص کنیم. تعریف رایج فرهنگ لغت از دامنه این است: "حوزه ای از دانش یا فعالیت". اما دامنه در قلمرو مهندسی نرم افزار عبارت است از «حوزه دانش و فعالیتی است که منطق برنامه حول آن می چرخد».

دامنه به موضوع خاصی اشاره دارد که پروژه برای آن در حال توسعه است.
یک دامنه محدوده عملیاتی شما یا برنامه مورد استفاده شما را مشخص می کند.

اصطلاح رایج دیگری که در طول توسعه نرم افزار استفاده می شود لایه دامنه یا منطق دامنه است که ممکن است برای بسیاری از توسعه دهندگان به عنوان لایه business logic شناخته شود. business logic یک برنامه کاربردی به قوانین سطح بالاتر برای نحوه تعامل اشیاء با یکدیگر برای ایجاد و اصلاح داده های مدل شده اشاره دارد.

مدل دامنه دانش سازمان یافته و ساختار یافته شما از مشکل است. مدل دامنه باید واژگان و مفاهیم کلیدی حوزه مشکل را نشان دهد و باید روابط بین همه مجودیت ها در محدوده دامنه را مشخص کند.

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


دامنه در واقع یک مشکل است(DDD در مورد مشکلات به عنوان دامنه/Domain صحبت می کند)

طراحی دامنه محور بر ایده حل مشکلاتی که سازمان ها با آن مواجه هستند با تمرکز در قلب business logic برنامه به دست می آید.

بنابراین دامنه، دنیای کسب و کار مورد نظر است. هر زمان که عبارت "طراحی با محوریت دامنه" را می شنوید، باید آن را "طراحی مبتنی بر مشکل آن کسب و کار یا business " در نظر بگیرید.

دامنه دنیای کسب و کاری است که با آن کار می کنید و مشکلاتی که می خواهید حل کنید. این معمولا شامل قوانین، فرآیندها و سیستم های موجود است که باید به عنوان بخشی از راه حل شما یکپارچه شوند.

دامنه ایده ها، دانش و داده های است که شما بعنوان مشکلی سعی در حل آن دارید. اکثر کسب و کارها دارای عباراتی هستند که در چارچوب سازمانشان معنای خاصی دارند. آنها همچنین به احتمال زیاد معیارها، اهداف و مقاصدی دارند که مختص کسب و کار خودشان است.

تمام دانش پیرامون یک کسب و کار و نحوه عملکرد آن، دامنه پروژه طراحی شده توسط شما را تشکیل می دهد.

مدل(Model) راه حل شماست

مدل پروژه طراحی شده توسط دامنه راه حل شما برای حل این مشکل است.

مدل معمولاً جنبه ای از واقعیت یا چیزی مورد علاقه را نشان می دهد. مدل همچنین اغلب ساده‌سازی تصویر بزرگ‌تر است و بنابراین جنبه‌های مهم راه‌حل بر روی آن متمرکز می‌شوند در حالی که همه چیز نادیده گرفته می‌شود.
این بدان معناست که مدل شما باید دانش را حول یک مشکل خاص متمرکز کند که برای ارائه راه حل ساده و ساختار یافته است.

مدل دامنه (Domain Model)

بنابراین اگر دامنه دنیای کسب و کار است و مدل راه حل شماست، مدل دامنه چیست؟

مدل دامنه دانش سازمان یافته و ساختار یافته شما از مشکل است. مدل دامنه باید واژگان و مفاهیم کلیدی حوزه مشکل را نشان دهد و باید روابط بین همه موجودیتها در محدوده دامنه را مشخص کند.

مدل دامنه خود می تواند یک نمودار، نمونه کد یا حتی مستندات مکتوب مشکل باشد. نکته مهم این است که مدل دامنه باید برای همه کسانی که با پروژه درگیر هستند در دسترس و قابل درک باشد.

مدل دامنه همچنین باید واژگان اطراف پروژه را تعریف کند و باید به عنوان یک ابزار ارتباطی برای همه افراد درگیر عمل کند. زبان فراگیر(Ubiquitous Language) یک مفهوم بسیار مهم در طراحی دامنه محور است و بنابراین باید مستقیماً از مدل دامنه مشتق شود.

یکی از ایرادات بسیاری از پروژه های توسعه نرم افزار، درک نادرست از اصطلاحات، اهداف و راه حل های پیشنهادی است که در ابتدای توسعه به آنها اشاره شده است.

مدل دامنه باید به عنوان یک تصویر واضح از مشکلی که در حال حل شدن است و راه حل پیشنهادی عمل کند. بسیار مهم است که همه ذینفعان پروژه به مدل دامنه کمک کنند تا همه مفاهیم و تعاریف کلیدی واژگان پروژه و نحوه برخورد و حل مشکل را درک کنند.

چرا مدل دامنه (Domain Model) مهم است؟

کمی پیشتر گفتیم دامنه دنیای کسب و کار است و مدل راه حل شماست و مدل دامنه دانش ساختار یافته مشکل است.
اما چرا این امر برای طراحی دامنه محور مهم است؟ خوب، من فکر می کنم سه دلیل برای اهمیت یک Domain Model وجود دارد.

  • مدل دامنه و قلب طرح یکدیگر را شکل می دهند
    کدی که می نویسید باید کاملاً با مدل مشکلی که حل می کنید مرتبط باشد. هر کسی در تیم باید بتواند به کد شما نگاه کند و بفهمد که چگونه در مشکلی که شما حل می کنید اعمال می شود.
    هنگامی که توسعه دهندگان از مدل منحرف می شوند، کدی را می نویسند که حول مدل ذهنی آنها از مشکل ساخته شده است. کدی که می نویسید باید مستقیماً از مدل دامنه توافق شده، مشتق شده باشد تا اطمینان حاصل شود که راه حل شما با الزامات کسب و کار مطابقت دارد.
  • مدل دامنه ستون فقرات زبانی است که توسط همه اعضای تیم استفاده می شود
    تک تک افراد تیم پروژه باید از زبان همه جا استفاده کنند. این به این معنی است که افراد فنی و غیر فنی زبان مشترکی (Ubiquitous Language) برای برقراری ارتباط دارند.
    زبان مشترک باید مستقیماً از Domain Model مشتق شود و بنابراین بدون Domain Model زبان Ubiquitous ندارید.
    بدون زبان مشترک، شما شروع به احساس اصطکاک در ارتباطات و از دست دادن درک بین اعضای فنی و غیر فنی تیم خواهید کرد. اگر کد نوشته شده شروع به انحراف از الزامات کارشناسان کسب و کار کند، راه حل نهایی اهداف پروژه را برآورده نمی کند.
  • مدل دامنه دانش تقطیر است
    مدل دامنه باید نتیجه یک فرآیند کشف تکراری باشد که در آن همه اعضای تیم برای بحث در مورد مشکلی که با آن روبرو هستید و چگونگی حل آن ملاقات می کنند.
    این همکاری اولیه بین کارشناسان دامنه و تیم توسعه برای موفقیت پروژه بسیار مهم است.
    مدل دامنه باید نحوه تفکر شما در مورد پروژه و تمام دانش حاصل از آن جلسات همکاری را نشان دهد.
    هر زمان که نیاز به تصمیم گیری در طول پروژه باشد، همه باید به مدل دامنه مراجعه کنند تا به دنبال پاسخ باشند یا سعی کنند به طور مکرر طرح را تکامل دهند تا حقیقتی پنهان را کشف کنند که قبلاً آشکار نشده است.

چگونه به یک مدل دامنه(Domain Model) می رسید؟

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

کارشناسان کسب و کار در مورد راه حل های فنی صحبت نمی کنند، بنابراین وظیفه شماست که مشکلات آنها را به درستی به راه حل های فنی تفسیر کنید.

در طول این فرآیند، جنبه های مهم مسئله باید از زبان انتخاب شود و تعاریف مشخصی برای شکل دادن به زبان همه جا ارائه شود.

واقعاً فرقی نمی‌کند که Domain Model به صورت کد، نمودار یا نوشته مکتوب ایجاد شود. با این حال باید یک حلقه بازخورد فشرده وجود داشته باشد که در آن همه افراد پروژه درباره مدل دامنه پیشنهادی بحث کنند تا به راه حل نزدیکتر شوند. این یک رویکرد تکراری است که احتمالاً شامل کد، نمودار و نوشته مکتوب برای درک واقعی مشکل و کشف راه حل صحیح است.

نتیجه

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

رسیدن به یک مدل دامنه مستحکم برای یک مشکل مشخص، یک رویکرد تکراری از همکاری بین کارشناسان تجاری و تیم فنی است. این باید به عنوان منبع درستی برای پروژه عمل کند و با پیشرفت پروژه یک سند زنده است.

در نهایت Domain Model مدلی انتزاعی از دامنه ی فعالیت نرم افزار است که توسط تیم توسعه ی نرم افزار در قالب یک مدل شی گراء طراحی می شود. این مدل ممکن است در طول زمان و با تغییر فرآیند ها تغییر یافته و تکمیل شود. Domain Model تنها یک ساختار داده ای نبوده و مجموعه ای از داده ها، رفتارها و قوانین (Business Rule) می باشد. از آنجا که مهم ترین چیز در طراحی Domain Model اطمینان از صحت فرآیند ها و Business نرم افزار می باشد، لذا هنگام طراحی از پرداختن به دغدغه ها و نکات فنی زیر ساختی و دیتابیسی خودداری می شود.(اصل Persistence Ignorance)

اصل Persistence Ignorance

این اصل می گوید کلاس ها باید روی مشکل کسب و کار تمرکز داشته باشند. هیچ چیز دیگری نباید در کلاس های Domain Model باشد.همچنین از آن به عنوان کلاس های POCO یاد می کنند.

در مستندات (MSDN) مربوط Entity Framework، اصل Persistence Ignorance به این صورت تعریف می شود: یک شی که حاوی هیچ منطقی نیست که مربوط به ذخیره سازی داده باشد.
در یک شیء Persistence Ignorance یا کلاس POCO هیچ سازنده یا متدی وجود ندارد.
الگوی Repository Pattern راه حلی برای محقق نمودن این اصل است. این الگو به شما کمک می‌کند که دامین شما درگیر نکات فنی زیر ساختی و دیتابیسی نشود.

نمونه ای از مدل دامنه (Domain Model) چیست؟

نشان دادن نمونه ای از یک مدل دامنه دشوار است زیرا باید واقعاً از یک مشکل کسب و کار در دنیای واقعی گرفته شود.

اما قبل از هر چیز و برای پیاده سازی Domain Model نیاز به دانستن مفاهیم(Tactical Design) و اجزای سازنده آن داریم :

طراحی دامنه محور DDD برای موفقیت پروژه‌های نرم افزار الگو‌ها و اصول متفاوتی را ارائه داده است که برخی از این الگو‌ها بیشتر مربوط به شناخت نرم افزار می‌شوند که اصلاحا آن‌ها را Strategic Pattern می‌نامیم و دسته دیگر که بیشتر مربوط به نحوه پیاده سازی Domain Model می‌شود را Tactical Pattern می‌نامیم.


بیشتر بخوانید : نقشه راه توسعه دهندگان Asp.NET Core


https://zarinp.al/farshidazizi


ddddomain driven designdomain layer
Software Engineer
شاید از این پست‌ها خوشتان بیاید