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

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

تعریف Exception ها

یکی از قسمت های مهم فرآیند مدل کردن فکر کردن در رابطه با چیزهایی هست که منجر به پذیرفته نشدن یک Command می شود. چنین مواردی را که با نام مسیرهای ناراحت (Sad Paths) نیز معرفی می‌شوند را بصورت Exception ها مدل می کنیم. پیشنهاد می کنیم مفهوم Happy Path و Sad Path را بررسی کنید. دقت کنید که Command ها و Event ها در قالب DTO ها مدل می شوند. این یکی از نقاط تمایز این دو مورد با Exception ها می باشد. Exception ها می توانند حاوی جزئیاتی در رابطه با اینکه چرا Command مورد نظر پذیرفته نشد باشند.

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

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

یکی از مزیت های استفاده از Exception ها برای مدل کردن چنین مواردی این است که Front End برنامه باید توسط Domain Logic مطلع شود که چه اتفاق ناخوشایندی رخ داده است. اینکه Front End برنامه با بررسی بعضی از State ها تلاش به کشف کردن مشکل به وجود آمده باشد کند یا حتی کاربر سعی به حدس زدن مشکل به وجود آمده کند روش کاملا اشتباهی است.

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

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

با بررسی دقیق سناریو مطرح شده در قسمت های قبلی در رابطه با Domain می توانیم متوجه بشیم که Exception های زیر ممکن است رخ دهند:

  • CannotCancelServedItem
  • TabHasUnservedItems
  • MustPayEnough

دقت کنید که در نامگذاری Exception ها چرایی اینکه Command پذیرفته‌ نشد در نظر گرفته می شود. برای مثال نمیتوان ایتم سرو شده را کنسل کرد و یا تب حاوی ایتم های غیر سرو شده می باشد.

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

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

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