آموزش معماری مدرن نرم افزارها CQRS و Domain Model و Event Sourcing

آموزش معماری مدرن نرم افزارها CQRS و Domain Model و Event Sourcing یکی دیگر از آموزش های گروه آموزشی پرووید می باشد که در این قسمت آن را به شما معرفی می کنیم. این بسته ی آموزشی نیز یکی از دوره های آموزشی دیگر که در حوزه ی فارسی سازی آموزش های انگلیسی تنظیم شده است می باشد. عنوان این بسته ی آموزشی معماری مدرن نرم افزار Domain Model، CQRS و Event Sourcing است که با نام اصلی Modern Software Architecture Domain Models, CQRS, and Event Sourcing از شرکت Pluralsight منتشر شده است.

Domain Model چیست؟

به منظور مشخص شدن مفهوم Domain Model باید ابتدا هر کدام از این دو واژه را به صورت جداگانه بررسی کنیم. Domain به معنی فضا یا حوزه ای است که در حال توسعه ی سیستم برای آن هستیم. مثال هایی از Domain شامل این موارد هستند: مدیریت خطوط هوایی، بیمه، کافی شاپ، دانشگاه و غیره. ممکن است محدوده ی یک سیستم شامل چندین Domain باشد. برای مثال، محدوده ی یک سیستم فروش آنلاین دامین های از این قبیل باشد: ارسال محصول (انتخاب بهترین روش های ارسال محصول با در نظر گرفتن محصول و مقصد)، قیمت گذاری (تخفیف گذاری ها و تبلیغات) و پیشنهادهای خرید (مشخص کردن محصولات مرتبط با توجه به سابقه ی خرید)

مفهوم کلمه ی Model یک تخمین از مسئله ی پیش رو است. برای مثال، کلاس Employee یک تخمین از ماهیت تمام و کمال یک کارمند در یک Domain است. بدون شک در یک کلاس Employee تمامی ویژگی ها و رفتارهای یک کارمند را قرار نمی دهیم، بلکه فقط مواردی که در Domain مورد نظر اهمیت دارند قرار میگیرند. موضوع دیگر اینکه ممکن است کلاس Employee در یک Domain به صورت متفاوتی نسبت به یک Domain دیگر مدل شود. برای مثال، دامین صدور حقوق و دامین منابع انسانی یک کارمند را به روش های متفاوتی مدل می کنند.

و نهایتاً مفهوم Domain Model همان Model ی است که برای Domain مورد نظر پیاده سازی می شود. CQRS و Event Sourcing چیست؟

CQRS سرنام چهار کلمه ی Command Query Responsibility Segregation باشد که به معنی تفکیک وظایف Command و Query ها در نرم افزار است. در واقع، Command ها درخواست های نوشتن و Query ها درخواست های خواندن می باشند که باید توسط اشیا متفاوتی مدیریت و انجام شوند. مسائل متنوع زیادی در مورد موضوع CQRS وجود دارد که اغلب با Domain Driven Design گره خورده اند. قرار دادن دو بانک اطلاعاتی در برنامه به منظور انجام عملیات خواندن و نوشتن به صورت جداگانه از هر کدام از این بانک ها ساده ترین شکل الگوی CQRS می باشد. در تصویر زیر شکل ساده از این الگو را مشاهده می کنید.

CQRS چیست و چه تفاوتی با معماری سنتی دارد؟

CQRS مخفف Command Query Responsibility Segregation است و رویکردی برای جدا کردن مسئولیت عملیات تغییر داده‌ها از عملیات خواندن آن‌ها محسوب می‌شود. در این الگو، Commandها برای درخواست تغییر وضعیت سیستم و Queryها برای دریافت اطلاعات به کار می‌روند. این جداسازی به توسعه‌دهندگان اجازه می‌دهد منطق هر نوع عملیات را متناسب با نیاز آن طراحی کنند. CQRS الزاماً به معنای استفاده از دو پایگاه داده مستقل نیست و می‌تواند با ساختارهای متفاوتی پیاده‌سازی شود.

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

Event Sourcing چیست و چگونه کار می کند؟

Event Sourcing رویکردی برای نگهداری وضعیت سیستم است که در آن تغییرات به‌صورت رویدادهای ثبت‌شده ذخیره می‌شوند، نه اینکه تنها آخرین وضعیت موجود نگهداری شود. در این روش، مجموعه رویدادهای مرتبط می‌تواند برای بازسازی وضعیت یک موجودیت مورد استفاده قرار گیرد. برای مثال، به‌جای ذخیره صرفاً وضعیت فعلی یک حساب، می‌توان رویدادهای واریز و برداشت را ثبت کرد و موجودی را از روی آن‌ها محاسبه کرد. این مدل، تاریخچه تغییرات را به بخش مهمی از طراحی سیستم تبدیل می‌کند.

پیاده‌سازی Event Sourcing نیازمند توجه به ترتیب رویدادها، نسخه‌بندی ساختار آن‌ها و نحوه بازسازی وضعیت است. همچنین برای پاسخ‌گویی سریع به درخواست‌های خواندن، می‌توان از مدل‌های نمایشی یا Read Model استفاده کرد که از روی رویدادها به‌روزرسانی می‌شوند. این رویکرد با ذخیره‌سازی معمولی تفاوت دارد و ممکن است پیچیدگی بیشتری در مدیریت داده‌ها ایجاد کند. به همین دلیل، استفاده از آن زمانی منطقی‌تر است که نگهداری تاریخچه تغییرات و بازسازی وضعیت، ارزش مشخصی برای سیستم داشته باشد.

معماری Layered در طراحی Domain Driven Design چه نقشی دارد؟

معماری Layered یا لایه‌ای، مسئولیت‌های نرم‌افزار را در بخش‌هایی با وظایف مشخص سازماندهی می‌کند. در طراحی مبتنی بر Domain Driven Design، لایه‌ها معمولاً برای تفکیک منطق دامنه از بخش‌هایی مانند Application، رابط کاربری و زیرساخت به کار می‌روند. این ساختار کمک می‌کند هر بخش روی مسئولیت اصلی خود تمرکز داشته باشد و وابستگی میان منطق کسب‌وکار و جزئیات فنی کنترل شود. تعریف درست مرزهای لایه‌ها در حفظ انسجام مدل دامنه اهمیت زیادی دارد.

در یک طراحی لایه‌ای مناسب، منطق دامنه نباید بدون ضرورت به فناوری‌های رابط کاربری یا جزئیات پایگاه داده وابسته باشد. لایه Application می‌تواند اجرای عملیات مورد نیاز سیستم را هماهنگ کند، در حالی که لایه‌های دیگر مسئول ارائه اطلاعات یا پیاده‌سازی ارتباطات فنی هستند. البته صرف تقسیم کد به چند پوشه یا پروژه به معنای ایجاد معماری لایه‌ای مؤثر نیست. مهم آن است که مسئولیت‌ها به‌درستی تعریف شوند و وابستگی‌ها با اصول طراحی انتخاب‌شده سازگار باشند.

چه زمانی باید از Domain Model و Event Sourcing استفاده کنیم؟

انتخاب میان مدل‌سازی دامنه، CQRS و Event Sourcing به نیازهای کسب‌وکار و ماهیت سیستم بستگی دارد. Domain Model زمانی اهمیت پیدا می‌کند که قوانین و رفتارهای کسب‌وکار پیچیده باشند و لازم باشد این منطق به‌صورت روشن در نرم‌افزار نمایش داده شود. چنین مدلی به توسعه‌دهندگان کمک می‌کند مفاهیم اصلی دامنه را از جزئیات فنی جدا کنند و تغییرات را بر اساس قواعد مشخص انجام دهند. پیچیدگی دامنه، یکی از عوامل مهم در تصمیم‌گیری برای انتخاب روش مناسب مدل‌سازی است.

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