این یک داستان در مورد نکاتی است که در هنگام پیاده سازی الگوی معماری CQRS باید در نظر گرفته شود. این نوشته بر گرفته از تجربیات مختلف در مورد پیاده سازی الگوی CQRS در شرکت های مختلف می باشد. در این نوشته سعی شده است مشکلاتی که در طول پیاده سازی الگوی CQRS برخورد کرده ام، به صورت خلاصه به اشتراک گذاشته شود و امیدوارم این نکات مورد توجه شما قرار بگیرید.
1 : مهمترین موضوع در هنگام استفاده کردن از الگوی معماری CQRS این است که هر بیزینسی نیاز به این الگو ندارد به عنوان مثال در بیزنس های بزرگ معمولا یک یا دو میکروسرویس داریم که خیلی نیاز به پیاده سازی الگوی CQRS دارند که معمولا جزو Core Domain بیزینس می باشند. در سایر موارد پیاده سازی CQS کافی می باشد.
(منظور بنده استفاده از شدو دیتا یا data redundant برای جلوگیری از ارسال درخواست زیاد و کنترل ترافیک شبکه نیست )
2-هنگام پیاده سازی الگوی CQRS اگر شما یک Application داشته باشید که دو کانکشن به دیتابیس های مختلف داشته باشد یعنی شما دو نوع Entity دارید یعنی دو نوع DomainEntity خواهید داشت و دو نوع Repository و دو نوع Service و غیره.
از هر چیز در Application دو نوع دارید که برای این جداسازی باید سراغ راهکار های مختلفی بروید که خود باعث پیچیدگی می شود. در هنگامی که دیتابیس های مختلف دارید بهتر است Application برای R/W را جدا کنید .چون باعث پیچیدگی Application می شود.
3-در پیازه سازی الگوی CQRS در بیشتر مواقع در زمان انجام عملیات Write شما نیاز به Read های سریع به داده های که همین الان تغییر یافته یا نوشته شده اند دارید و نمی توانید منتظر Sync شدن دیتابیس ها باشید. در این صورت باید از دیتابیس Write برای انجام عملیات Read های لحظه ی نیز استفاده کنید.
. اشاره به مورد اول شما دو نوع Read خواهید داشت Read از دیتابیس Read و Read از دیتابیس Write پس بهتر است Application برای R/W را جدا کنید .چون باعث پیچیدگی می شود.
4-معولا برای گزارش های پیچیده و محدودی که شاید در پروژهای بزرگ نیز کمتر از 10 مورد باشد (10 عددی تقریبی می باشد) . شما مشکل performance و پیاده سازی الگوی CQRS دارید و از دیتابیس Read باید حتما خوانده شوند و بقیه Read ها مشکل پرفرمنسی ندارند و از همان دیتابیس Write هم می تواند خوانده شوند
5-در الگوی CQRS معمولا دیتابیس های NOSQL برای Read و دیتابیس های SQL برای Write انتخاب می شوند .که این دوتا تکنلوژی مختلف می باشند بهتر است برای جلوگیری از پیچیدگی برنامه از همان ابتدا Application ها جدا طراحی شوند. اپلیکیشن های سبک نگهداری راحت تری دارند.
6- معمولا تعداد درخواست های Read از خواست های Write بیشتر است, (البته به نوع اپلیکیشن وابسته است) . شاید نیاز باشد شما اپلیکشن Read را به تعداد زیاد Scale کنید. درصورتی که در اپلیکیشن Write نیاز به این کار نداشته باشید. پس بهتر است Application برای R/W جدا طراحی شوند.
7-نکته ی آخر این که بهتراست در ابتدا اپلیکیشن را برای CQS (یعنی یک دیتابیس ) طراحی کنید. بعد از راه اندازی و عملیاتی شدن نسخه اولیه، می توانید Application برای قسمت read را نیز طراحی نمایید. که از همان اول درگیر مفاهیم پیچیده Outbox و inbox و عملیات Sync نشوید و حتی شاید بعدا نظرتان در مورد روش و الگو های انتخابی تغییر کند.
#softwarearchitecture #softwaredevelopment #softwareengineering #softwaredesign #arcitecturepatterns #performance #microservices #microservicesarchitecture #cqrs
