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

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

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

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

دانلود کتاب

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

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

معنی دامنه (Domain)

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

هسته‌ی اصلی 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، از پیاده‌سازی درست و دقیق این فرآیندها اطمینان حاصل کند. ( آموزش EF Core )

معنی 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). این نوع نگاه و طراحی، به روز تر و مناسب‌تر می‌باشد!

مفهوم Persistence Ignorance

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

امکان تست Doman Layer

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

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

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

 به قلم داریوش تصدیقی

آموزش EF Core

مجله اینترنتی توزلو