Domain Driven Design - بخش چهارم

در این پست، به بررسی مفهوم Consistency در طراحی مبتنی بر DDD می‌پردازیم. انواع مختلف یکپارچگی داده‌ها، از جمله Atomic Consistency و Eventual Consistency، و تأثیر آن‌ها بر طراحی سیستم‌های نرم‌افزاری مورد بحث قرار می‌گیرند. همچنین، ارتباط این مفاهیم با قواعد ACID، BASE و CAP تحلیل شده و با ارائه یک مثال عملی از سیستم حراجی (Auction)، نحوه پیاده‌سازی این اصول در یک مدل دامنه نشان داده می‌شود.

در طراحی سیستم‌های نرم‌افزاری، حفظ یکپارچگی داده‌ها (Consistency) یکی از چالش‌های اساسی است. در Domain Driven Design، این مفهوم نقش کلیدی در طراحی مدل دامنه و تعیین مرزهای Aggregateها دارد. در این پست، به بررسی دو رویکرد اصلی در یکپارچگی داده‌ها می‌پردازیم:

• Atomic Consistency
• Eventual Consistency

انواع Consistency

Atomic Consistency

در این نوع یکپارچگی، عملیات به صورت Atomic انجام می‌شود، یعنی یا تمام مراحل با موفقیت اجرا می‌شوند یا هیچ‌کدام اجرا نمی‌شوند. مثال کلاسیـک این مفهوم، انتقال پول بین دو حساب است:

• اگر مبلغی از حساب A کم شود، باید حتماً به حساب B اضافه شود.
• در صورت بروز خطا در هر مرحله، تمام تغییرات Rollback می‌شوند.

این رویکرد مبتنی بر اصول ACID (Atomic Consistent Isolated Durable) است.

Eventual Consistency

در این مدل، سیستم ممکن است در لحظه‌ای خاص ناسازگار باشد، اما در نهایت به حالت یکپارچه می‌رسد. برای مثال:

• در انتقال پول، ممکن است مبلغ از حساب A کم شود اما با تأخیر به حساب B اضافه شود.
• این روش در سیستم‌های توزیع‌شده و NoSQL رایج است و مبتنی بر قاعده BASE (Basic Availability Soft-state Eventual consistency) است.

قاعده CAP و تأثیر آن بر Consistency
قاعده CAP بیان می‌کند که در یک سیستم توزیع‌شده، تنها دو مورد از سه ویژگی زیر را می‌توان همزمان تضمین کرد:

• Consistency (یکپارچگی)
• Availability (در دسترس بودن)
• Partition Tolerance (تحمل تقسیم‌بندی)

مثال:

فرض کنید یک دیتابیس به سه Node تقسیم شده است:

• اگر Consistency را انتخاب کنیم، سیستم باید منتظر Sync شدن تمام Nodeها بماند (کاهش Availability).
• اگر Availability را انتخاب کنیم، سیستم داده‌ی موجود را فوراً برمی‌گرداند (کاهش Consistency).
• اگر Partition Tolerance را کنار بگذاریم، سیستم دیگر توزیع‌شده نیست.

کاربرد Consistency در Domain Driven Design

در DDD، مفهوم Aggregateها مرزهای تراکنشی را تعیین می‌کنند:

• درون یک Aggregate: از Transactional Consistency استفاده می‌شود.
• بین Aggregateها: از Eventual Consistency استفاده می‌شود.

مثال عملی: سیستم حراجی (Auction)

در یک سیستم حراجی، موجودیت‌های اصلی شامل:

• Auction (حراج)
• Bid (پیشنهاد)
• WinningBid (پیشنهاد برنده)
• Seller (فروشنده)
• Bidder (پیشنهاددهنده)
• Product (کالا)

و Invariantهای سیستم شامل:

• قیمت شروع باید بزرگتر از صفر باشد.
• پیشنهاد اول باید بیشتر از قیمت شروع باشد.
• پیشنهادهای بعدی باید از آخرین پیشنهاد بیشتر باشند.
• پیشنهادها فقط روی حراج‌های باز ثبت شوند.

طراحی Aggregate:

• موجودیت‌های Auction و WinningBid در یک Aggregate قرار می‌گیرند تا Transactional Consistency را تضمین کنند.
• موجودیت‌ Bid (تاریخچه پیشنهادها) به صورت Eventual Consistency از طریق Eventهای Async ذخیره می‌شود.
  

مدیریت Eventual Consistency

در این سیستم، ممکن است بین ذخیره‌ی WinningBid و Bid تأخیر وجود داشته باشد. اما از آنجا که کاربران بیشتر به آخرین پیشنهاد توجه دارند، این تأخیر مشکلی ایجاد نمی‌کند. راه‌حل‌های ساده مانند نمایش زمان آخرین به‌روزرسانی می‌تواند شفافیت را افزایش دهد.

نتیجه‌گیری

انتخاب نوع Consistency به نیازهای کسب‌وکار و معماری سیستم بستگی دارد:

• مفهوم Atomic Consistency برای عملیات‌های بحرانی مانند تراکنش‌های بانکی مناسب است.
• مفهوم Eventual Consistency در سیستم‌های توزیع‌شده و NoSQL کاربرد دارد.

در DDD، طراحی Aggregateها نقش کلیدی در تعیین مرزهای تراکنشی و مدیریت یکپارچگی داده‌ها دارد.