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

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

برای مثال، در یک سیستم فروش، مفهوم مشتری ممکن است در بخش سفارشگیری با مفاهیم مورد استفاده در بخش حسابداری تفاوت داشته باشد. بهجای تحمیل یک مدل واحد به همه بخشها، میتوان برای هر محدوده مدل متناسبی تعریف کرد. در طراحی چنین ساختاری، شناخت مرزهای مسئولیت و ارتباط میان بخشها اهمیت زیادی دارد. توسعهدهندگانی که با Bounded Context کار میکنند، میتوانند پیچیدگی مدل دامنه را بهتر مدیریت کنند و تغییرات هر بخش را با استقلال بیشتری پیش ببرند.
Aggregate و Repository در طراحی دامنه محور چه کاربردی دارند؟
Aggregate در Domain Driven Design مجموعهای از اشیای دامنه است که بهعنوان یک واحد منسجم مدیریت میشود. این ساختار کمک میکند قواعد و محدودیتهای کسبوکار در محدوده مشخصی اعمال شوند و تغییر وضعیت اشیای مرتبط به شکل کنترلشده صورت بگیرد. ریشه Aggregate یا Aggregate Root نقطه ورود برای دسترسی و تغییر اعضای این مجموعه است. استفاده درست از این مفهوم باعث میشود مسئولیت حفظ سازگاری دادهها و اجرای قوانین دامنه در طراحی نرمافزار روشنتر باشد.
Repository نیز الگویی برای دسترسی به اشیای دامنه و بازیابی یا ذخیرهسازی آنهاست، بدون اینکه منطق کسبوکار مستقیماً با جزئیات پایگاه داده درگیر شود. در این رویکرد، کد دامنه میتواند با مفاهیم خود مدل کار کند و جزئیات نگهداری دادهها در بخش مناسب دیگری قرار بگیرد. ترکیب Aggregate و Repository به طراحی ساختاریافتهتر مدل دامنه کمک میکند. انتخاب مرزهای درست برای Aggregateها نیز اهمیت دارد، زیرا بر نحوه مدیریت تغییرات و سازگاری اطلاعات در سیستم تأثیر میگذارد.
Domain Event چیست و چه زمانی استفاده می شود؟
Domain Event رویدادی است که وقوع یک اتفاق مهم در دامنه کسبوکار را بیان میکند. برای مثال، ثبت موفق یک سفارش یا تأیید پرداخت میتواند بهعنوان یک رویداد دامنه در نظر گرفته شود. این رویدادها به سیستم اجازه میدهند اتفاقات مهم را به شکلی صریح بیان کند و بخشهای دیگر برنامه بتوانند در صورت نیاز به آنها واکنش نشان دهند. استفاده از Domain Event میتواند وابستگی مستقیم میان بخشهایی را که به یک اتفاق مشترک علاقهمند هستند کاهش دهد.
در طراحی مبتنی بر Domain Driven Design، رویدادهای دامنه باید معنای مشخصی در زبان کسبوکار داشته باشند و صرفاً بازتاب جزئیات فنی نباشند. برای نمونه، رویداد «سفارش ثبت شد» بیانگر یک اتفاق واقعی در دامنه است، در حالی که رویدادی مانند «یک متد اجرا شد» لزوماً چنین معنایی ندارد. تعریف دقیق رویدادها به سازماندهی بهتر منطق برنامه کمک میکند و امکان توسعه رفتارهای جدید را فراهم میسازد. در سیستمهای پیچیده، مدیریت صحیح این رویدادها نیازمند توجه به ترتیب اجرا و سازگاری وضعیت دادههاست.
مدل دامنه در نرم افزارهای پیچیده چگونه بهبود پیدا می کند؟
مدل دامنه مجموعهای از مفاهیم و قواعد است که دانش کسبوکار را در ساختار نرمافزار بازتاب میدهد. این مدل نباید صرفاً مجموعهای از کلاسهای داده باشد، بلکه لازم است رفتارها، محدودیتها و روابط معنادار دامنه را نیز نمایش دهد. با شناخت بهتر نیازهای کسبوکار و بررسی مشکلات مدل موجود، میتوان ساختار آن را بهتدریج اصلاح کرد. این فرایند به توسعهدهندگان کمک میکند نرمافزاری بسازند که با تغییر نیازهای واقعی کسبوکار سازگارتر باقی بماند.
بهبود مدل دامنه معمولاً با بازبینی مسئولیت اشیا، شفاف کردن مفاهیم و اصلاح مرزهای میان بخشهای مختلف همراه است. اگر یک کلاس مسئولیتهای نامرتبط زیادی داشته باشد یا قواعد مهم کسبوکار در چند نقطه پراکنده شده باشند، ممکن است مدل به بازطراحی نیاز داشته باشد. توجه به ارتباط میان مدل دامنه و زبان مشترک تیم نیز در این فرایند اهمیت دارد. هدف، ایجاد مدلی سادهتر و دقیقتر است که فهم منطق سیستم و توسعه قابلیتهای جدید را آسانتر کند.
سرفصل مطالب آموزش کاربردی طراحی نرم افزار Domain Driven Design
فصل اول: مقدمه
- شروع به کار
- سرفصل این دوره ی آموزشی و پیش نیازها
- حوزه های کاربر Domain Driven Design
- چرا باید از Domain Driven Design استفاده کنیم؟
- مفاهیم اساسی در Domain Driven Design
- Domain Driven Design لزوماً مربوط به کد نویسی نیست
- معماری پیازی و Domain Isolation
- بهترین تکنیک های مدل سازی
- ارتباط Domain Driven Design و Unit Testing
- معرفی نرم افزار این بسته ی آموزشی یا همان دامین مسئله (Domain Problem)
- جمع بندی
فصل دوم: شروع به کار با اولین Bounded Context
- مقدمه
- واژگان مورد استفاده
- توصیف مسئله
- شروع به کار با انتیتی Snack Machine
- مرور شروع به کار با انتیتی Snack Machine
- مقایسه ی Entity ها و Value Object ها
- نحوه ی شناخت Value Object ها در Domain Model
- معرفی کلاس پدر Entity ها
- پیاده سازی عملی کلاس پدر Entity ها
- مرور کلاس پدر Entity ها
- معرفی کلاس پدر Value Object ها
- مرور کلاس پدر Value Object ها
- مقایسه ی Value Object ها و Value Type ها در دات نت
- زمان مناسب نوشتن Unit Test
- پیاده سازی کلاس Money
- اتمام پیاده سازی کلاس Money
- پیاده سازی کلاس Snack Machine
- مرور پیاده سازی کلاس Money و کلاس Snack Machine
- جمع بندی
فصل سوم: معرفی لایه های UI و Persistence
- مقدمه
- Application Service ها و UI در معماری پیازی
- افزودن UI برای Snack Machine
- مرور افزودن UI برای Snack Machine
- طراحی بانک اطلاعاتی برای Snack Machine
- معرفی NHibernate به عنوان یک ORM
- استراتژی های ID Generation
- استراتژی های Mapping
- تنظیم Domain Layer برای استفاده شدن در ORM
- تنظیم موارد دیگر
- جمع بندی
فصل چهارم: گسترش دادن Bounded Context با استفاده از Aggregate ها
- مقدمه
- توصیف مسئله
- شروع به کار با پیاده سازی
- معرفی Aggregate ها
- نحوه ی پیدا کردن مرزهای Aggregate ها
- معرفی کلاس پدر Aggregate Root
- ریفکتور کردن Snack Machine به عنوان یک Aggregate
- مرور ریفکتور کردن Snack Machine به عنوان یک Aggregate
- پیاده سازی نیازمندی های دیگر
- پدیدار شدن نیازمندهای مخفی
- مرور پدیدار شدن نیازمندهای مخفی
- جمع بندی
فصل پنجم: معرفی Repository ها
- مقدمه
- تنظیم کردن بانک اطلاعاتی برای Entity های جدید
- معرفی Repository ها
- معرفی کلاس پدر Repository ها
- پیاده سازی Mapping ها برای Aggregate ها
- ریفکتور کردن انتیتی Snack
- تنظیم UI برنامه
- جمع بندی
فصل ششم: معرفی Bounded Context دوم
- مقدمه
- پیاده سازی یک مدل جدید برای یک ATM
- Bounded Context های موجود
- مقایسه ی مفهوم Bounded Context و Sub Domain
- انتخاب کردن مرزهای Bounded Context ها
- تشکیل دادن یک Context Map
- انواع Physical Isolation ها
- ارتباطات بین Bounded Context ها
- Code Reuse (استفاده ی مجدد از کد) بین Bounded Context ها
- پیاده سازی Domain Logic مربوط به انتیتی ATM
- تنظیم کردن بانک اطلاعاتی
- افزودن UI
- جمع بندی
فصل هفتم: کار با Domain Event ها
- مقدمه
- نیازمندی های جدید
- معرفی یک Bounded Context جدید
- اولین تلاش در پیاده سازی
- معرفی Domain Event ها
- مبحث Physical Delivery
- ساخت Management به عنوان یک Bounded Context
- هندل کردن Domain Event ها با روش سنتی
- مرور روش سنتی
- یک روش بهتر برای هندل کردن Domain Event ها
- مرور روش بهتر
- استفاده از Domain Event ها برای ارتباط بین Microservice ها
- اضافه کردن UI برای Management به عنوان یک Bounded Context
- جمع بندی
فصل هشتم: بهبود بیشتر نرم افزار و Domain Model
- مقدمه
- مقایسه ی روش Always Valid و Not Always Valid
- معرفی Factory ها
- مقایسه ی Domain Service ها و Application Service ها
- ضدالگوی Anemic Domain Model
- ضدالگوی Fat Entity
- ضدالگوهای Repository ها
- روش برخورد Mechanical با Domain Driven Design
- بهبودهای دیگر
- جمع بندی
- لیست منابع
- خلاصه ی بسته ی آموزشی







