Web Devs

🔰وقتی سیستم‌ها با هم حرف می‌زنند:
Command vs Event vs Pub/Sub

معمولا پیام هایی که در بین سیستم ها تبادل می شود در دو دسته قرار دارن.

❇ در دسته اول فرستنده پیام هایی میفرسته که مشخص کننده اینکه یک عملیات باید انجام بشه، مثل PlaceOrder که به معنی "ثبت سفارش‌جدید " هست. این نوع پیام‌ها Command نام دارند.

در مورد Command، بین فرستنده (sender) و گیرنده (receiver) یک وابستگی منطقی (logical coupling) وجود داره، چون فرستنده می‌دونه که گیرنده باید با اون دستور چی کار کنه.

این یعنی فرستنده دقیقاً مشخص می‌کنه چه کاری باید انجام بشه (مثلاً "سفارش ثبت کن") و فرض می‌گیره که گیرنده توانایی انجامش رو داره.

دستورها (Commands) معمولاً فقط توسط یک گیرنده پردازش می‌شن، که این موضوع باعث انعطاف‌پذیری کمتری می‌شه.

📌 برای مثال: اگر بخوای چند سیستم همزمان به یک Command پاسخ بدن، باید تغییراتی در منطق اون Command ایجاد کنی که برخلاف اصل Open/Closed هست.

❇ در دسته دوم Event ها هستن، Event ها فقط اطلاع میدن که "یه اتفاق افتاده"، مثلاً OrderCreated یعنی "سفارش ثبت شد".

🚨 فرقش با Command اینه که Event یه گزارشه از یه چیزیه ک تموم‌شده، نه درخواست اجرای یه عملیات.

و Eventها loosely coupled هستن چون فرستنده اصلاً نمی‌دونه که چه کسی قراره به این پیام واکنش نشون بده یا چطور باهاش برخورد بشه. فرستنده فقط می‌گه: "این اتفاق افتاد" .

دلیل این موضوع هم اینه که Event ها معمولاً بر اساس الگوی(Publish/Subscribe) کار می‌کنن. یعنی یه نفر Event رو publish می‌کنه، و هر کسی که به اون Event علاقه‌منده (subscriber) اون رو دریافت می‌کنه.

به‌خاطر این وابستگیه کمی که Publish/Subscribe در بین Publisher و Subscriber ایجاد می‌کنه، در خیلی از موارد استفاده از Event ها ترجیح داده میشن نسبت به Commandها.

یکی از مزایای مهم Event اینه که می‌تونی Subscriber جدید اضافه کنی بدون اینکه کدهای موجود رو تغییر بدی.

💡 این خیلی ارزشمنده چون توسعه سیستم رو بدون درگیر شدن با بقیه بخش‌ها ممکن می‌کنه.

یعنی تیم بیزینس می‌تونه یه Bounded Context جدید به راحتی اضافه کنه، بدون اینکه به کدهای فعلی دست بزنه یا کار تیم‌های دیگه رو مختل کنه.

📌 مثلاً در مثال فروشگاه اینترنتی، اگر OrderCreated منتشر بشه، تیم مارکتینگ فقط با Subscribe کردن به اون Event می‌تونه وارد جریان بشه، بدون اینکه توی سیستم سفارش‌گذاری اصلی دخالتی ایجاد کنه.

@fullStackDevs

👍5

www.tgoop.com/fullStackDevs/755

319 viewsJul 11 at 10:17

🔰وقتی سیستم‌ها با هم حرف می‌زنند:
Command vs Event vs Pub/Sub

معمولا پیام هایی که در بین سیستم ها تبادل می شود در دو دسته قرار دارن.

❇ در دسته اول فرستنده پیام هایی میفرسته که مشخص کننده اینکه یک عملیات باید انجام بشه، مثل PlaceOrder که به معنی "ثبت سفارش‌جدید " هست. این نوع پیام‌ها Command نام دارند.

در مورد Command، بین فرستنده (sender) و گیرنده (receiver) یک وابستگی منطقی (logical coupling) وجود داره، چون فرستنده می‌دونه که گیرنده باید با اون دستور چی کار کنه.

این یعنی فرستنده دقیقاً مشخص می‌کنه چه کاری باید انجام بشه (مثلاً "سفارش ثبت کن") و فرض می‌گیره که گیرنده توانایی انجامش رو داره.

دستورها (Commands) معمولاً فقط توسط یک گیرنده پردازش می‌شن، که این موضوع باعث انعطاف‌پذیری کمتری می‌شه.

📌 برای مثال: اگر بخوای چند سیستم همزمان به یک Command پاسخ بدن، باید تغییراتی در منطق اون Command ایجاد کنی که برخلاف اصل Open/Closed هست.

❇ در دسته دوم Event ها هستن، Event ها فقط اطلاع میدن که "یه اتفاق افتاده"، مثلاً OrderCreated یعنی "سفارش ثبت شد".

🚨 فرقش با Command اینه که Event یه گزارشه از یه چیزیه ک تموم‌شده، نه درخواست اجرای یه عملیات.

و Eventها loosely coupled هستن چون فرستنده اصلاً نمی‌دونه که چه کسی قراره به این پیام واکنش نشون بده یا چطور باهاش برخورد بشه. فرستنده فقط می‌گه: "این اتفاق افتاد" .

دلیل این موضوع هم اینه که Event ها معمولاً بر اساس الگوی(Publish/Subscribe) کار می‌کنن. یعنی یه نفر Event رو publish می‌کنه، و هر کسی که به اون Event علاقه‌منده (subscriber) اون رو دریافت می‌کنه.

به‌خاطر این وابستگیه کمی که Publish/Subscribe در بین Publisher و Subscriber ایجاد می‌کنه، در خیلی از موارد استفاده از Event ها ترجیح داده میشن نسبت به Commandها.

یکی از مزایای مهم Event اینه که می‌تونی Subscriber جدید اضافه کنی بدون اینکه کدهای موجود رو تغییر بدی.

💡 این خیلی ارزشمنده چون توسعه سیستم رو بدون درگیر شدن با بقیه بخش‌ها ممکن می‌کنه.

یعنی تیم بیزینس می‌تونه یه Bounded Context جدید به راحتی اضافه کنه، بدون اینکه به کدهای فعلی دست بزنه یا کار تیم‌های دیگه رو مختل کنه.

📌 مثلاً در مثال فروشگاه اینترنتی، اگر OrderCreated منتشر بشه، تیم مارکتینگ فقط با Subscribe کردن به اون Event می‌تونه وارد جریان بشه، بدون اینکه توی سیستم سفارش‌گذاری اصلی دخالتی ایجاد کنه.

@fullStackDevs

BY Web Devs