cqrs

مخزن خواندن جدا کمک می‌کند داده را برای یک صفحه یا گزارش و نه برای نیازهای مدل نوشتن شکل دهیم. این کار می‌تواند join‌های پرهزینه را کم کند و ظرفیت خواندن را مستقل افزایش دهد.

در عوض، یک مسئله‌ی همگام‌سازی به وجود می‌آید. ممکن است داده‌ی خواندنی قدیمی باشد و نمایش باید بتواند به‌طور امن بازیابی شود و برنامه باید روشن کند کاربر پس از ارسال یک command چه چیزی می‌بیند.

CQRS لازم نیست از همان روز اول با دو پایگاه‌داده و چند سرویس شروع شود. می‌توان مسیر command و مسیر query را در همان برنامه و پایگاه‌داده جدا کرد، چون کارشان واقعاً یکی نیست.

مسیر command از تغییر محافظت می‌کند و مسیر query پاسخ مناسب فراخواننده را می‌سازد. این انتخاب تراکنش و خواندن فوری را نگه می‌دارد، اما مقیاس‌پذیری مستقل خواندن را به دست نمی‌دهد.

یک DTO تغییرکرده فقط می‌گوید وضعیت چه شده است، نه اینکه کاربر دقیقاً چه کاری خواسته. وقتی تغییر به مجوز، دلیل یا قانون‌های دیگر گره می‌خورد، این تفاوت مهم می‌شود.

command با نام روشن، مثل `DeactivateInventoryItem`، هدف کاربر را مستقیم به برنامه می‌رساند. بعد اعتبارسنجی، مجوزدهی و قواعد همان عمل در یک نقطه می‌مانند.

برای تغییر نام نمایشی یا یک تنظیم ساده، CRUD کاملاً کافی است. مسئله از جایی شروع می‌شود که تغییر چند فیلد، یک تصمیم کسب‌وکار با مجوز، دلیل و پیامدهای خودش را پنهان می‌کند.

این نوشته نشان می‌دهد چرا گاهی باید به‌جای فرستادن یک DTO تغییرکرده، خود عمل را نام ببریم. CQS و CQRS برای همین نقطه‌اند، نه برای پیچیده کردن هر update معمولی.