آموزش عملی و پروژه محور Domain Driven Design و CQRS #5 قسمت پنجم از یک سری آموزشی از وبسایت پرووید است که در رابطه با Domain Driven Design و CQRS تنظیم شده است. پس از این دوره ی آموزشی می توانید از بسته های آموزشی وبسایت پرووید در رابطه با Domain Driven Design را استفاده کنید.

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

تعریف Aggregate ها

دقت کنید که در Domain افعال به تنهایی نمی‌توانند کار زیادی را انجام بدهند. بدون شک به استفاده از اسم ها هم نیاز داریم. اگر بخواهیم به طور دقیق‌تر بگوییم استفاده از اسم ها برای تعریف کردن State جاری سیستم ضروری هستند. یکی از موارد استفاده از State ها تصمیم گرفتن در رابطه با پذیرفته شدن یا عدم پذیرفته شدن Command ها می باشد. برای مثال در Domain ما برای اینکه Command کنسل کردن یک سفارش پذیرفته شود باید بررسی کنیم و ببینیم آیا State آن سفارش در حالت سرو شده قرار دارد یا نه چرا که در سناریوی که در قسمت های قبلی تعریف کردیم ذکر کردیم که سفارشی که سرو شده باشد و مشتری آن را پذیرفته باشد امکان کنسل شدن را ندارد.

بسته ی آموزش کاربردی طراحی نرم افزار Domain Driven Design

از شما دعوت می کنیم از بسته ی آموزش کاربردی طراحی نرم افزار Domain Driven Design دیدن کنید.

دقت کنید که تمامی اطلاعاتی که ما به آن نیاز داریم در مجموعه‌ Event هایی که رخ داده ‌اند می باشند چرا که آنها تمامی حقایق وارد شده به سیستم را ثبت و ضبط کرده اند. موضوع مهمتر اینکه برای تصمیم گیری در رابطه با پذیرفته شدن یا عدم پذیرفته شدن یک Command نیازی به تمامی Event های رخ داده شده نداریم. در واقع ما فقط به Event هایی که برای تصمیم ‌گیری در رابطه با آن موضوع خاص به ما کمک می کنند اهمیت می دهیم. برای مثال تمامی Event هایی که در رابطه با یک تب (مفهموم تب در Domain کافی شاپ را در قسمت اول این آموزش معرفی کنیم) خاص رخ دادند که با استفاده از آنها می‌توانیم پذیرفته شدن یا عدم پذیرفته شدن Command کنسل کردن سفارش را مشخص کنیم.

با این حساب به مفهوم Aggregate ها میرسیم. هر Aggregate مجموعه Event های خاص خودش را دارد که با در نظر گرفتن تمامی آنها می‌توانیم State فعلی آن Aggregate را مشخص کنیم. Aggregate ها از همدیگر کاملاً تفکیک (Isolated) شده هستند. تصمیم در رابطه با اینکه یک Command باید پذیرفته شود یا نه صرفاً بر اساس خود آن Command و اطلاعات موجود در Event های رخ داده برای یک Aggregate انجام می شود.

بسته ی آموزش اصول طراحی نرم افزار Domain Driven Design

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

به طور کلی Aggregate ها یکی از دو مورد زیر هستند:

  • یک Object که به هیچ Object دیگری رفرنس نمی زند.
  • یک گراف تفکیک شده از Object ها که که یکی از آنها را به عنوان ریشه میشناسیم و دنیای بیرون از آن Aggregate فقط آن ریشه را می شناسند.

طراحی Aggregate ها کار ساده ای نیست چرا که ما را الزام می‌کنند که مفاهیم تجاری (Business Concepts) را کشف و از هم تفکیک کنیم. علاوه بر این موضوع به این معنی است که ما باید به طور کامل بر روی مرزهای سازگاری (Consistency Boundaries) تمرکز کنیم.

در Domain کافی شاپ ما فقط یک Aggregate به نام تب وجود دارد. با این وجود ممکن است در بسیاری از نرم افزارهای دیگر نیاز به کشف Aggregate های بیشتری باشد. به طور کلی آغاز کار از مدل کردن Event ها و Command ها و سپس گروه بندی کردن آن ها بر اساس Invariant ها (قوانین تجاری که باید برقرار باشند) راهکاری مناسب است.

در ادامه کار نوشتن موارد تست (Test Case) را آغاز میکنیم و Domain Logic را میسازیم. همینطور که مشغول به این کار می‌شویم جنبه‌های مختلف طراحی خود را مرور کرده و جزئیات مربوط به Command ها و Event ها را بررسی می کنیم.

در قسمت بعدی از این آموزش در مورد پیاده سازی Domain Logic و اولین Command و Event صحبت خواهیم کرد.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *