آموزش Domain Driven Design (DDD) + EF Core (مقدمه)

توجه: این مقاله به مرور زمان، ویرایش و یا تکمیل می‌شود!
تقاضا: در صورتی که با مشکل تایپی، دستوری و یا مفهومی در این مقاله برخورد کردید، از شما دوست عزیز و گرامی، صمیمانه تقاضا می‌کنم که اینجانب را مطلع کرده، تا نسبت به تصحیح و یا تکمیل آن، در اسرع وقت، اقدام نمایم.
با کمال تشکر
داریوش تصدیقی
کانال تلگرام: IranianExperts@
شماره تلفن همراه: ۰۹۱۲۱۰۸۷۴۶۱
نشانی پست الکترونیکی: DariushT@GMail.com
فیلم‌های آموزشی https://www.aparat.com/DariushT
آدرس سایت‌ها:
https://WebsiteAnalytics.ir - http://IranianExperts.ir - http://Date2Date.ir - https://DTApp.ir

نسخه مقاله: ۱.۴ - تاریخ بروزرسانی: ۱۴۰۰/۰۳/۰۷

دامنه (Domain)

اصطلاح Domain، به دامنه (حوزه) اصلی فعالیت (عملیات) سامانه نرم‌افزاری اطلاق می شود.

درباره Domain Driven Design

به Domain Driven Design، به اختصار DDD گفته می‌شود.

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

به طور کلی DDD مبحثی است که در سال‌های اخیر به شدت مورد توجه جامعه‌ی نرم‌افزاری دنیا قرار گرفته و رویکرد بسیاری از شرکت‌های نرم افزاری را برای تحلیل و توسعه‌ی نرم‌افزارها، به شدت مورد تاثیر قرار داده است. این مبحث اولین بار در سال ۲۰۰۳ توسط آقای Eric Evans در کتاب Domain Driven Design مطرح گردید.

دانلود کتاب

نکته:‌ متخصصین DDD، معمولا به این کتاب، Blue Book می‌گویند.

فیلم سخنرانی آقای Eric Evans در خصوص DDD

طراحی دامنه محور (DDD) چیست؟

به طور کلی می‌توان گفت که DDD رویکردی است برای تولید و توسعه‌ی نرم‌افزارهای بزرگ، با فرآیندها و قوانین زیاد، پیچیده و در حال تغییر!

هسته‌ی اصلی DDD مجموعه‌ای از مفاهیم و تکنیک‌هاست که برای تحلیل Domain و ساخت یک مدل از روی آن (Domain Model) به کار برده می‌شود.

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

در زمان ایجاد Domain Model، با دقت به جزئیات توجه کرده و مفاهیم و قوانین (‌Business Rule) را در آن پیاده‌سازی می‌کنیم.

متخصص دامنه (Domain Expert)

به کسانی که بر روی موضوع سامانه اشراف داشته و یا به صورت سنتی، حال بدون سامانه و یا با سامانه‌های قدیمی کار کرده‌اند و می‌خواهند سامانه جدیدی برای آن‌ها طراحی و پیاده‌سازی شود، اصطلاحا متخصص دامنه (Domain Expert) اطلاق می‌شود. مانند انبارداران در سامانه انبارداری و یا حسابداران در برنامه حسابداری و غیره.

طراحی به روش DDD بر زوایای دیگری از فرآیند توسعه‌ی نرم افزار نیز تاثیر‌گذار است. برای مثال تاکید زیادی در ارتباط (دائم و متناوب) دو طرفه‌ی تیم توسعه‌ی نرم‌افزار و کاربران متخصص دامنه وجود دارد.

زبان مشترک و یکسان (Ubiquitous Language)

از آنجا که ممکن است در ارتباط دو طرفه تیم توسعه‌ی نرم افزار و متخصصین دامنه، مشکل و اشتباهی در درک متقابل از لغات، مفاهیم و موجودیت‌ها وجود داشته و یا به وجود آید، و در فهمیدن برخی مفاهیم و مسائل دچار اشتباه و دوگانگی شوند، لذا ایجاد یک زبان مشترک و یکسان بین دو تیم (Ubiquitous Language) در مورد مفاهیم Domain، امری الزامی است.

بخش جدا و مستقل (Bounded Context)

در DDD همچنین راهکارهایی برای تقسیم نرم افزار به بخش‌های جدا و مستقل (مفهوم Bounded Context) و همچنین ارتباط این بخش‌ها با یکدیگر ارائه می‌گردد. این امر سبب می شود تا فرآیند توسعه‌ی نرم افزار، به صورت موازی، بین چند تیم انجام شده و همچنین معماران سیستم قادر خواهند بود تا از معماری‌ها و تکنولوژی‌های مختلفی در بخش‌های مختلف استفاده نمایند.

رویکرد DDD برای چه نوع سامانه‌هایی مناسب است؟

به طور کلی، رویکرد DDD برای نرم‌افزارها و سامانه‌های بزرگ و پیچیده مناسب می‌باشد. لذا استفاده از آن در پروژه‌های کوچک و ساده و یا پروژه‌هایی که صرفا نیاز به ذخیره و خواندن اطلاعات دارند و Business خاصی ندارند، ممکن است تنها زمان و هزینه‌ی پروژه را افزایش داده و مزیت خاصی ایجاد نمی‌کنند.

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

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

تیم توسعه‌دهنده نرم‌افزار می‌تواند با تمرکز بر روی Domain و طراحی مدل دامنه (Domain Model) از روی آن و همچنین با رعایت مفاهیم و تکنیک‌های DDD، از پیاده‌سازی درست و دقیق این فرآیندها اطمینان حاصل کند.

معنی Domain Centric

در معماری Onion، زمانی که دامنه و مفاهیم آن در مرکز سامانه و یا توجه قرار داشته باشند و طراحی و پیاده‌سازی سامانه، بر اساس طراحی و پیاده‌سازی دامنه آن هم در ابتدای کار در نظر گرفته شود، اصطلاحا می‌گوییم که این معماری بر اساس روش Domain Centric‌ توسعه پیدا کرده است.

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

کدام رویه را به کار می‌بریم (Anemic or Rich Domain Model)؟

در تهیه و تنظیم این‌گونه مقالات، فرض بر آن است که ما به جای ایجاد Domain Model هایی ساده که صرفا ساختار داده‌ای ساده داشته و با استفاده از Domain Service‌ ها اقدام به تجهیز آن‌ها، به رفتارها و نیز قوانین تجاری نماییم (Anemic Domain Model)، از Domain Model‌ هایی استفاده می‌کنیم که علاوه بر ساختار داده‌ای پیشرفته، رفتارها و نیز قوانین تجاری و حتی Validation ها آن‌ها نیز در درون خود Domain Model ها قرار داشته باشند (Rich Domain Model). این نوع نگاه و طراحی، مدرن‌تر و مناسب‌تر می‌باشد!

اصل PI = Persistence Ignorance

از آنجا که مهم‌ترین موضوع در طراحی Domain Model، اطمینان از صحت فرآیند‌ها، Business ها و اعتبارسنجی مدل‌های سامانه نرم‌افزاری می‌باشد، لذا در هنگام طراحی و پیاده‌سازی Domain Model ها، از پرداختن به دغدغه‌ها و نکات فنی و زیرساختی، در خصوص مفاهیم بانک‌های اطلاعاتی و واسط کاربری (UI) اجتناب می‌کنیم.

زمانی که در هنگام طراحی و پیاده‌سازی لایه‌ای از سامانه، از دغدغه‌ها و نکات دیتابیسی (Database) و یا کلا ذخیره‌سازی داده به هر شکل، اجتناب نماییم، اصطلاحا اعلام می‌کنیم که در طراحی و پیاده‌سازی این لایه، از اصل Persistence Ignorance تبعیت کرده‌ایم.

عدم وابستگی به بانک‌های اطلاعاتی و واسط کاربر، دقیقا به چه معنا است؟

در زمان تحلیل، طراحی و پیاده‌سازی لایه Domain، به هیچ عنوان نباید برای ما اهمیت داشته باشد که پروژه با چه بانک اطلاعاتی کار می‌کند! SQL Server, MySQL, MongoDB و غیره. به هیچ عنوان نباید برای ما اهمیت داشته باشد که به چه روشی به بانک‌های اطلاعاتی متصل شده و داده‌ها را رد و بدل می‌کنیم! ADO.NET, EF Core, Dapper, NHibernate‌ و غیره. به هیچ عنوان نباید برای ما اهمیت داشته باشد که واسط کاربری ما چیست و به شکلی پیاده‌سازی می‌شود! Windows Forms, ASP.NET Core MVC, Web Api و غیره.

امکان تست Doman Layer

از آنجایی که می‌خواهیم عملیات طراحی و پیاده‌سازی خود را به روش Rich Domain Model انجام داده و در زمان پیاده‌سازی نیز از هرگونه دغدغه و نکات فنی و زیرساختی، در خصوص مفاهیم بانک‌های اطلاعاتی و واسط کاربری (UI) اجتناب نماییم، شاید یکی از زیبایی‌ها و جذابیت‌های طراحی به روش DDD آن باشد که می‌توان به راحتی بر روی این لایه از سامانه (Domain Layer)، سیستم Unit Testing راه‌اندازی نماییم!

اکثر مباحث مطرح شده در DDD، در راستای تحلیل و پیاده‌سازی Domain Model می‌باشد و برای این منظور به آموزش مفاهیمی نیاز داریم که در این مسیر، دقت و سهولت در طراحی را به همراه دارد، این مفاهیم عبارتند از:

• Event
• Entity
• Value Object
• Business Rule
• Aggregate Root
• Domain Context
• Bounded Context
• Sub Domain Context
• Strongly Typed Enum (Enumeration)

تشکر و قدردانی

از تمامی دوستان و عزیزانی که در ویرایش شکلی و ماهوی این مجموعه مقالات به اینجانب کمک می‌کنند، صمیمانه تشکر و قدردانی می‌کنم.

• آقای داریوش اقتداری
• خانم مرضیه طاریم

مراجع

مقاله آقای مهندس دلپاک عزیز

مقاله آقای مهندس هادی احمدی عزیز

ده اشتباه رایجی که نباید در طراحی و پیاده‌سازی متدلوژی DDD مرتکب شویم!

پایان