معماری نرم افزار – فصل چهارم – بخش اول

فصل ۴: مؤلفه‌های منطقی — اجزای سازنده

آماده‌ای معماری سیستم رو طراحی کنی؟ اون‌قدر که به نظر می‌رسه ساده نیست—اگه درست انجامش ندی، ممکنه کل سیستم نرم‌ افزارت مثل یه برج یا پلی که بد طراحی‌ شده به هم بریزه.

تو این فصل قراره چندتا روش یاد بگیری برای اینکه مؤلفه‌های منطقی (کامپوننت) سیستم رو شناسایی و طراحی کنی—همون بخش‌های کاربردی‌ای که نشون می‌دن اجزای سیستم چطور کنار هم قرار می‌گیرن. با استفاده از تکنیک‌های این فصل، می‌تونی یه معماری محکم بسازی؛ یه پایه‌ی درست‌وحسابی برای یه سیستم نرم‌ افزاری موفق.

کلاه ایمنی‌تو بذار، دستکش‌هاتو بپوش، ابزارها رو آماده کن—بزن بریم!

مروری دوباره بر مؤلفه‌های منطقی (Logical components)

مؤلفه‌های منطقی یکی از بُعدهای معماری نرم‌ افزار هستن. اینا همون بخش‌های کاربردی سیستم‌ان که حوزه‌ی مسئله (Problem Domain) رو شکل می‌دن. تو فصل اول یه آشنایی اولیه باهاشون داشتی، ولی تو این فصل قراره عمیق‌تر بریم سراغ اینکه مؤلفه‌های منطقی دقیقاً چی‌ان و چطور باید طراحی‌شون کنیم.

یادت باشه که تو بیشتر زبان‌های برنامه‌نویسی، مؤلفه‌های منطقی (logical components) معمولاً از طریق ساختار پوشه‌های سورس‌کد مشخص می‌شن. مثلاً اگه کدی تو مسیر app/order/tracking باشه، اون بخش می‌تونه یه مؤلفه‌ی منطقی به اسم «پیگیری سفارش» (Order Tracking) باشه.

شرکت Adventurous Auctions وارد دنیای آنلاین می‌شه

می‌خوای بری سافاری تو تانزانیا؟ حیات‌وحش گالاپاگوس رو از نزدیک ببینی؟ یا تا کمپ اصلی اورست پیاده‌روی کنی؟ شرکت Adventurous Auctions اینجاست که همچین سفرهایی رو برات ممکن کنه!
اینجور سفرها خیلی خاصن و ممکنه سال‌ها طول بکشه تا نوبتت بشه، ولی این شرکت با مزایده و تخفیف‌های حسابی، دسترسی بهشون رو آسون‌تر کرده.

حالا هدفشون اینه که آدم‌های بیشتری از سراسر دنیا بتونن به این سفرها دسترسی داشته باشن—واسه همین دارن مزایده‌هاشونو آنلاین هم برگزار می‌کنن، علاوه بر حالت حضوری.

و اینجاست که تو وارد بازی می‌شی: یه سیستم جدید لازم داریم که مزایده‌های آنلاین این سفرهای ماجراجویانه رو پشتیبانی کنه.

سیستمی که قراره برای مزایده‌های آنلاین Adventurous Auctions ساخته بشه باید این کارها رو انجام بده:

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

معماری منطقی در برابر معماری فیزیکی

معماری منطقی نشون می‌ده اجزای اصلی سیستم چی‌ان و چطور با هم ارتباط دارن (که بهش می‌گن coupling).
ولی معماری فیزیکی چیزهایی مثل سبک معماری، سرویس‌ها، پروتکل‌ها، دیتابیس‌ها، رابط‌های کاربری، API Gatewayها و موارد مشابه رو نشون می‌ده.

معماری منطقی یه سیستم مستقل از معماری فیزیکی‌اشه—یعنی معماری منطقی کاری به دیتابیس، سرویس‌ها، پروتکل‌ها و این چیزا نداره.

بیایم یه مثال بزنیم از اینکه منظورمون از معماری منطقی چیه. یادت هست که Adventurous Auctions باید بتونه مزایده‌های آنلاین رو ایجاد و زمان‌بندی کنه، و به شرکت‌کننده‌ها اجازه بده ثبت‌نام کنن، مزایده‌ها رو جست‌وجو کنن، و سفرهایی که برای مزایده گذاشته شدن رو ببینن.

اینا چندتا از مؤلفه‌هایی‌ان—همون بلوک‌های کاربردی سیستم—که قراره این کارها رو ممکن کنن.

می‌بینی که معماری منطقی شامل اون اجزای فیزیکی‌ای که گفتیم نیست؟ این یه نگاه متفاوت به سیستمه.
اگه نمودار معماری منطقی رو با نمودار معماری فیزیکی بعدی مقایسه کنی، متوجه می‌شی که معماری فیزیکی سرویس‌ها رو به مؤلفه‌های منطقی وصل می‌کنه و همین‌طور سرویس‌ها و دیتابیس‌های سیستم رو هم نشون می‌ده.

طراحی معماری منطقی

شناسایی مؤلفه‌های منطقی اون‌قدر که به نظر می‌رسه ساده نیست. برای کمک، یه فلوچارت آماده کردیم. نگران نباش—توی صفحات بعدی همه‌ی مراحلش رو کامل توضیح می‌دیم.

این روند تا وقتی سیستم زنده‌ست ادامه داره.

این فلوچارت یه سری مراحل رو نشون می‌ده برای شروع پروژه‌های جدید (greenfield) و همین‌طور نگهداری مداوم سیستم‌هایی که از قبل وجود دارن.
تا حالا برات سؤال شده چرا یه سیستم خوش‌ساخت خیلی زود تبدیل می‌شه به یه آشفته‌بازار غیرقابل نگهداری؟ دلیلش اینه که تیم‌ها به معماری منطقی سیستم‌هاشون اون‌طور که باید توجه نمی‌کنن.

هر بار که قراره چیزی رو تغییر بدی یا یه قابلیت جدید اضافه کنی، باید این مراحل رو دوباره طی کنی تا مطمئن بشی مؤلفه‌های منطقی اندازه‌شون مناسبه و دقیقاً همون کاری رو می‌کنن که باید.

مرحله‌ی اول: شناسایی کامپوننت‌های اصلی اولیه

اولین قدم برای ساختن معماری منطقی اینه که مؤلفه‌های اصلی اولیه رو پیدا کنی. خیلی وقتا این کار بیشتر یه حدس زدنه تا یه تحلیل دقیق، و احتمال زیاد بعداً مجبور می‌شی همین مؤلفه‌هایی که اول انتخاب کردی رو بازطراحی یا تقسیم‌بندی کنی.
پس فعلاً خودتو درگیر اندازه‌ی مؤلفه‌ها نکن—بعداً بهش می‌رسیم. اول بذار نشونت بدیم منظورمون از «حدس زدن» چیه.

مدیر ارشد فناوری اطلاعات (CIO) شرکت Adventurous Auctions روند مزایده رو اینطور توضیح میده:
روند مزایده خیلی ساده‌ست: شرکت‌کننده‌ها وارد یه مزایده‌ی زنده می‌شن، اون رو تماشا می‌کنن، و روی سفری که بهش علاقه دارن پیشنهاد قیمت می‌دن.

با توجه به این توضیح ساده، می‌تونی کار رو با ساختن سه مؤلفه‌ی منطقی شروع کنی—هر کدوم برای یکی از سه کاری که سیستم قراره انجام بده.

این مؤلفه‌ها فعلاً کاری انجام نمی‌دن. در واقع، فقط شناسایی‌شون کردیم ولی هنوز هیچ مسئولیتی بهشون ندادیم. می‌تونی مثل یه سری ظرف خالی بهشون نگاه کنی—یه حدس اولیه بر اساس کارهای اصلی‌ای که توی سیستم اتفاق می‌افته. واسه همین بهشون می‌گیم مؤلفه‌های اصلی اولیه.

چندتا روش وجود داره که می‌تونه حدس و گمان رو تا حدی از این کار حذف کنه.

الان هنوز اطلاعات زیادی از سیستم یا نیازهاش نداری، و مؤلفه‌هایی که اول شناسایی می‌کنی احتمالاً با گذشت زمان تغییر می‌کنن. واسه همین می‌گیم تو این مرحله یه جور بازی حدس زدنه—و این کاملاً طبیعیه!

قراره دوتا روش رایج برای شناسایی مؤلفه‌های اصلی اولیه بهت نشون بدیم: روش مبتنی بر جریان کار (workflow) و روش بازیگر/عمل (actor/action).

یه سری روش دیگه هم هست که اولش خوب به نظر می‌رسن ولی ممکنه حسابی گمراهت کنن. اونارو بعد از اینکه روش‌های درست رو گفتیم، بررسی می‌کنیم.

رویکرد جریان کاری (Workflow Approach)

رویکرد جریان کاری یه روش مؤثره برای شناسایی مجموعه‌ای اولیه از مؤلفه‌های اصلی سیستم. تو این روش، به جریان‌های اصلی کاری فکر می‌کنی—یعنی مسیرهایی که کاربر ممکنه توی سیستم طی کنه.
لازم نیست همه‌ی جزئیات رو از اول ثبت کنی؛ فقط با مراحل پردازشی اصلی شروع کن و بعد کم‌کم وارد جزئیات بیشتر شو.

بیایم از رویکرد جریان کاری استفاده کنیم تا چند مؤلفه‌ی اصلی اولیه برای معماری Adventurous Auctions شناسایی کنیم.

پرسش: شما مؤلفه‌ای به نام «Video Streamer» رو به‌عنوان یه مؤلفه‌ی منطقی شناسایی کردید، ولی اگه تیم ما تصمیم بگیره از یه کتابخانه یا سرویس خارجی برای پخش مزایده استفاده کنه چی؟
پاسخ: سؤال خوبیه! حتی اگه خودتون اون قابلیت رو توسعه ندید، باز هم جزئی از معماری منطقی محسوب می‌شه.

پرسش: آیا هر مرحله در یه جریان کاری همیشه به یه مؤلفه‌ی منطقی واحد وصل می‌شه؟
پاسخ: نه همیشه. ممکنه چند مرحله از یه جریان کاری به یه مؤلفه‌ی منطقی مشترک اشاره کنن، مخصوصاً اگه عملکردهاشون به هم نزدیک باشه.

اسم‌ها مهمن

خیلی دقت کن به اینکه مؤلفه‌های اصلی اولیه رو چی نام‌گذاری می‌کنی. یه اسم خوب باید به‌صورت خلاصه و دقیق نشون بده اون مؤلفه چه کاری انجام می‌ده.

Trip Viewer
واضحه که این مؤلفه اجازه می‌ده سفرهایی رو که در مزایده قرار گرفتن ببینی. این یه اسم خوبه برای مؤلفه هست.

Auction Manager
کی می‌دونه این مؤلفه دقیقاً چه کاری انجام می‌ده؟
اسم خیلی خوبی نیست.

رویکرد بازیگر/عمل (Actor/Action Approach)

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

برگردیم به مثال Adventurous Auctions—بیایم با همین رویکرد چند مؤلفه‌ی اصلی اولیه رو شناسایی کنیم.

خریدار (Kate)

اقدامات:

• جست‌وجوی مزایده
• مشاهده‌ی پخش زنده‌ی ویدیو
• ثبت پیشنهاد

مؤلفه‌های (کامپوننت) مرتبط:

• Auction Search (جست‌وجوی مزایده)
• Video Streamer (پخش‌کننده‌ی ویدیو)
• Bid Capture (ثبت پیشنهاد)

مزایده‌گذار (Sam)

اقدامات:

• ورود به رابط مزایده‌ی زنده
• دریافت پیشنهاد از خریدار آنلاین
• شروع مزایده
• علامت‌گذاری آیتم به‌عنوان فروخته‌شده

مؤلفه‌های مرتبط:

• Live Auction Session (جلسه‌ی مزایده‌ی زنده)
• Automatic Payment (پرداخت خودکار)

بازیگر سیستمی

از بازیگر سیستمی برای نشون دادن چیزهایی که بطور اتوماتیک اتفاق میوفتن استفاده می‌کنیم.

اقدامات:

• دریافت هزینه از خریدار
• پیگیری فعالیت‌های خریدار

مؤلفه‌ی مرتبط:

• Bidder Tracker (ردیاب خریدار)

تله موجودیت (Entity Trap)

اگه تعداد زیادی عمل مرتبط با پیشنهاد قیمت شناسایی کنم، باید همه‌شون رو توی یه کامپوننت به اسم Bid Manager قرار بدم؟

به تله موجودیت خوش اومدی.
ما به این رویکرد می‌گیم تله موجودیت چون خیلی راحت می‌شه توش افتاد وقتی داری کامپوننت‌های اولیه رو شناسایی می‌کنی—و اگه این کار رو بکنی، با کلی مشکل مواجه می‌شی.

اول از همه، اسم «Bid Manager» خیلی مبهمه.
می‌تونی فقط با دیدن اسمش بفهمی این کامپوننت دقیقاً چه کاری انجام می‌ده؟
ما هم نمی‌تونیم.
اول اینکه این اسم اطلاعات کافی درباره‌ی نقش و مسئولیت‌های کامپوننت نمی‌ده.
دوم اینکه، این کامپوننت مسئولیت‌های زیادی داره.
کامپوننت‌هایی که در تله موجودیت می‌افتن، خیلی وقت‌ها تبدیل می‌شن به محل انباشت همه‌ی قابلیت‌های مرتبط با اون موجودیت.
در نتیجه، بیش از حد بزرگ می‌شن و نگهداری، مقیاس‌پذیری، و مقاوم‌سازی در برابر خطا (Fault Tolerant) براشون سخت می‌شه.

مراقب واژه‌هایی مثل «manager» یا «supervisor» باش وقتی می‌خوای کامپوننت‌های منطقی رو نام‌گذاری کنی—این‌ها نشونه‌های خوبی‌ان که ممکنه وارد تله موجودیت شده باشی.

سوال: رویکرد بازیگر/عمل خیلی منو یاد Event Storming می‌ندازه. آیا این دو یکی هستن؟

نکته‌ی خوبیه، و خوشحالیم که شباهت‌ها رو دیدی. Event Storming یه رویکرد مبتنی بر کارگاهه که بخشی از طراحی مبتنی بر دامنه (Domain Driven Design) محسوب می‌شه. توی این رویکرد، دامنه‌ی کسب‌وکار رو تحلیل می‌کنی تا رویدادهای دامنه رو شناسایی کنی.
در حالی که هر دو رویکرد هدف نهایی‌شون شناسایی اقدامات انجام‌شده در سیستمه، Event Storming در شناسایی کامپوننت‌ها خیلی فراتر از رویکرد بازیگر/عمل می‌ره.
می‌شه گفت رویکرد بازیگر/عمل عناصر بازیگر و رویداد دامنه در Event Storming رو شناسایی می‌کنه، ولی به سراغ عناصر دیگه مثل command، aggregate، view نمی‌ره.
می‌تونی اطلاعات بیشتر درباره‌ی Event Storming رو در اینجا بخونی:
https://en.wikipedia.org/wiki/Event_storming

سوال: آیا می‌تونم رویکرد جریان کاری و رویکرد بازیگر/عمل رو با هم ترکیب کنم، یا باید یکی رو انتخاب کنم؟

می‌تونی ترکیبشون کنی، و در بیشتر موارد این کار ایده‌ی خوبیه. اگه با رویکرد بازیگر/عمل شروع کنی تا اقدامات رو شناسایی کنی، بعد می‌تونی با رویکرد جریان کاری اون اقدامات رو به ترتیبی که احتمالاً رخ می‌دن مرتب کنی.

سوال: داری می‌گی که نباید هیچ‌وقت از واژه‌هایی مثل manager یا supervisor در نام کامپوننت‌هام استفاده کنم؟

نه الزاماً—هیچ قانون قطعی‌ای برای تله موجودیت وجود نداره. بعضی وقت‌ها پیدا کردن اسم برای چیزی که یه وظیفه‌ی عمومی انجام می‌ده سخت می‌شه. مثلاً یه کامپوننت که همه‌ی داده‌های مرجع اپلیکیشن رو مدیریت می‌کنه—جفت‌های نام/مقدار مثل کد کشور، کد فروشگاه، کد رنگ و غیره. یه اسم خوب برای چنین کامپوننتی می‌تونه “Reference Data Manager” باشه.
اما اسم‌هایی مثل “Order Manager” یا “Response Handler” خیلی کلی‌ان و مشخص نمی‌کنن که اون کامپوننت‌ها دقیقاً چه کاری انجام می‌دن.

سوال: وقتی از رویکرد بازیگر/عمل استفاده می‌کنیم، باید چند عمل برای هر بازیگر شناسایی کنیم؟

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

مرحله‌ی ۲: تخصیص نیازمندی‌ها

وقتی چند کامپوننت اصلی اولیه رو شناسایی کردی، وقتشه بری سراغ مرحله‌ی بعد: تخصیص نیازمندی‌ها به اون کامپوننت‌های منطقی.
تو این مرحله، داستان‌های کاربری یا نیازمندی‌های عملکردی رو بررسی می‌کنی و مشخص می‌کنی که هر کدوم باید به کدوم کامپوننت مربوط باشه.
یادت باشه، هر کامپوننت با یه ساختار دایرکتوری نمایش داده می‌شه. کد توی اون دایرکتوری قرار داره، پس اون نیازمندی هم داخل همون دایرکتوری خواهد بود.

بیایم برگردیم به مجموعه‌ی اولیه‌ی کامپوننت‌هایی که بر اساس صحبت‌های Frank (مدیر ارشد فناوری) درباره‌ی جریان کاری پایه‌ی Adventurous Auctions تعریف کردیم.
حالا وقتشه که برخی مسئولیت‌ها رو به این کامپوننت‌ها اختصاص بدیم.

نیازمندی	کامپوننت	توضیح
نمایش سفر فعلی که در حال مزایده است	Live Auction Session	چون این کامپوننت مسئول کنترل مزایده‌ی جاری است
علامت‌گذاری سفر به‌عنوان فروخته‌شده و رفتن به سفر بعدی	Live Auction Session	مرتبط با جریان مزایده، پس به همین کامپوننت اختصاص داده می‌شود
ارسال هر پیشنهاد آنلاین به مزایده‌گذار زنده در لحظه‌ی ثبت	Bid Capture	چون پیشنهاد را از خریدار دریافت می‌کند، منطقی است که آن را به مزایده‌گذار هم ارسال کند
ضبط پخش زنده‌ی ویدیو برای بازپخش در صورت اختلاف	Video Streamer	چون همین کامپوننت مسئول نمایش ویدیو است، ضبط آن نیز به آن سپرده می‌شود
نمایش جزئیات سفر فعلی برای خریداران	Trip Viewer (کامپوننت جدید)	هیچ کامپوننت قبلی مناسب این وظیفه نبود، پس کامپوننت جدیدی ایجاد شد

مرحله‌ی ۳: تحلیل نقش‌ها و مسئولیت‌ها

وقتی شروع به تخصیص قابلیت‌ها (یعنی داستان‌های کاربری یا نیازمندی‌ها) به کامپوننت‌های منطقی می‌کنی، نقش‌ها و مسئولیت‌های هر کامپوننت به‌طور طبیعی شروع به رشد می‌کنن.
هدف این مرحله اینه که مطمئن بشی کامپوننتی که بهش قابلیت اختصاص می‌دی واقعاً باید مسئول اون قابلیت باشه—و اینکه بیش از حد بار روی دوشش نذاری.

فرض کنیم کامپوننتی به نام Live Auction Session ایجاد کنیم که در طول مزایده‌ی زنده مسئولیت‌های زیر رو بر عهده داره:

با اضافه شدن قابلیت‌ها، این کامپوننت حالا مسئولیت‌های زیادی رو به عهده گرفته. این وضعیت رایجیه، پس اگه برای تو هم پیش اومد، تعجب نکن.
اگه چنین اتفاقی افتاد، نگران نشو—این مرحله دقیقاً برای همین طراحی شده.
بیایم ببینیم آیا می‌تونیم این وضعیت رو اصلاح کنیم و بخشی از مسئولیت‌های کامپوننت Live Auction Session رو به کامپوننت‌های دیگه منتقل کنیم.

نکته‌
تا حالا کلاسی به نام Utility ساختی؟ چی کار می‌کرد؟
احتمال زیاد شامل مجموعه‌ای از توابع نامرتبط بوده که نمی‌دونستی کجا بذاریشون.
همین اتفاق ممکنه برای کامپوننت‌های منطقی در معماری نرم‌ افزار هم بیفته.
سعی کن از ساخت کامپوننت‌هایی که شامل تعداد زیادی تابع نامرتبط هستن، خودداری کنی.

پایبندی به انسجام (Cohesion)

وقتی نقش و مسئولیت‌های یک کامپوننت یا مجموعه‌ای از عملیات‌هاش رو تحلیل می‌کنی، بررسی کن که آیا این قابلیت‌ها به‌طور نزدیکی به هم مرتبط هستن یا نه.
این موضوع با عنوان انسجام (Cohesion) شناخته می‌شه: درجه و نحوه‌ی ارتباط عملیات‌های یک کامپوننت با هم.
انسجام (Cohesion) ابزار مفیدیه برای اینکه مطمئن بشی کامپوننت مسئولیت‌های درستی داره.

در حین تحلیل نقش‌ها و مسئولیت‌های یک کامپوننت، معمولاً با موارد نامعمول (قابلیت‌هایی که وصله‌ی ناجور هستن) یا کامپوننت‌هایی که بیش از حد بار دارن مواجه می‌شی.
در این موارد، معمولاً بهتره بخشی از مسئولیت‌ها رو به کامپوننت‌های دیگه منتقل کنی.

مرحله‌ی ۴: تحلیل ویژگی‌های معماری

آخرین مرحله در شناسایی کامپوننت‌های اصلی اولیه اینه که بررسی کنیم آیا هر کامپوننت با ویژگی‌های معماری کلیدی‌ای که برای موفقیت حیاتی هستن هم‌راستا هست یا نه.
در بیشتر موارد، این کار شامل شکستن یک کامپوننت برای دستیابی به مقیاس‌پذیری (Scalability)، کشسانی (Elasticity) یا دسترسی‌پذیری (Availability) بهتره؛ ولی گاهی هم ممکنه لازم باشه کامپوننت‌هایی که عملکردها‌شون به‌شدت به هم وابسته‌ان، با هم ترکیب بشن.

بیایم دوباره به مثال Adventurous Auctions نگاه کنیم. قبلاً کامپوننتی به نام Bid Capture رو شناسایی کردیم که مسئول دریافت پیشنهادها، ذخیره‌ی همه‌ی پیشنهادها در پایگاه داده‌ی Bid Tracker، و ارسال بالاترین پیشنهاد به مزایده‌گذار بود.
در ادامه، جریان کلی عملکرد کامپوننت Bid Capture ارائه می‌شه.

روند پردازش پیشنهاد در مزایده‌ی زنده

۱. تصمیم‌گیری خریدار

• کاربر سفر را می‌پسندد و تصمیم می‌گیرد پیشنهاد خود را افزایش دهد.

۲. ثبت پیشنهاد در سیستم Bid Capture

• پیشنهاد کاربر به کامپوننت Bid Capture ارسال می‌شود.
• سیستم پیشنهاد را در پایگاه داده ذخیره می‌کند.

۳. تحلیل و تشخیص بالاترین پیشنهاد

• سیستم تشخیص می‌دهد که پیشنهاد کاربر بالاترین پیشنهاد فعلی است.

۴. اعلام پیشنهاد توسط مزایده‌گذار

• مزایده‌گذار پیشنهاد را دریافت می‌کند و آن را اعلام می‌کند.

این معماری خوب به نظر می‌رسه، اما برای اطمینان باید بررسی کنیم که کامپوننت Bid Capture از ویژگی‌های معماری حیاتی سیستم پشتیبانی می‌کنه—ویژگی‌هایی که برای موفقیت ضروری هستن:

• مقیاس‌پذیری (Scalability):
  سیستم باید بتونه هزاران پیشنهاد در ثانیه رو پشتیبانی کنه.
• دسترس‌پذیری (Availability):
  سیستم باید در طول برگزاری مزایده‌ها همیشه فعال و در دسترس باشه.
• کارایی (Performance):
  سیستم باید پیشنهاد رو دریافت کنه و در سریع‌ترین زمان ممکن به مزایده‌گذار برسونه.

کامپوننت Bid Capture باید طوری طراحی بشه که این سه ویژگی رو به‌خوبی پوشش بده.

تحلیل ویژگی‌های معماری کامپوننت Bid Capture

ذخیره یشنهادها در پایگاه داده توسط Bid Capture منطقیه، چون خودش اون‌ها رو دریافت می‌کنه.
اما اتصال به پایگاه داده و ظرفیت عبور داده (throughput) محدود هست، بنابراین واگذاری این مسئولیت به Bid Capture تأثیر قابل توجهی روی مقیاس‌پذیری داره.
همچنین روی کارایی تأثیر می‌ذاره چون زمان انتظار برای نوشتن داده به پایگاه داده اضافه می‌شه، و روی دسترس‌پذیری هم اثر داره اگر پایگاه داده از دسترس خارج بشه.

اگه ذخیره پیشنهادها تو دیتابیس رو به کامپوننت جدیدی به نام Bid Tracker اختصاص بدیم، می‌تونیم مقیاس‌پذیری، کارایی، و دسترس‌پذیری کامپوننت Bid Capture رو به‌طور قابل توجهی افزایش بدیم.
این باعث می‌شه سیستم بتونه تعداد بیشتری پیشنهاد رو سریع‌تر پردازش کنه و بالاترین پیشنهاد رو در کوتاه‌ترین زمان ممکن به مزایده‌گذار برسونه.
کامپوننت Bid Capture می‌تونه پیشنهادها رو به Bid Tracker ارسال کنه و دیگه لازم نیست منتظر نوشتن پیشنهاد در پایگاه داده بمونه.

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

روند پردازش پیشنهاد در مزایده‌ی زنده – پس از تغییرات

۱. دریافت پیشنهاد توسط Bid Capture

• خریدار پیشنهاد خود را ثبت می‌کند.
• کامپوننت Bid Capture پیشنهاد را دریافت می‌کند بدون اینکه آن را ذخیره کند.

۲. ارسال غیرهمزمان پیشنهاد به Bid Tracker

• کامپوننت Bid Capture پیشنهاد را به کامپوننت جدیدی به نام Bid Tracker ارسال می‌کند.
• این ارسال به‌صورت غیرهمزمان انجام می‌شود، یعنی Bid Capture منتظر ذخیره‌سازی نمی‌ماند.

۳. ذخیره‌سازی پیشنهاد توسط Bid Tracker

• کامپوننت Bid Tracker مسئول ذخیره‌سازی پیشنهادها در پایگاه داده است.
• چون این کامپوننت مستقل عمل می‌کند، می‌تواند با سرعت دلخواه داده‌ها را ذخیره کند بدون اینکه روی عملکرد مزایده تأثیر بگذارد.

۴. افزایش سرعت پردازش پیشنهادها

• چون Bid Capture دیگر درگیر ذخیره‌سازی نیست، می‌تواند تعداد بیشتری پیشنهاد را در زمان کمتر پردازش کند.

۵. بهبود تجربه مزایده‌گذار

• مزایده‌گذار دیگر لازم نیست منتظر ذخیره‌شدن هر پیشنهاد در پایگاه داده بماند.
• بالاترین پیشنهاد سریع‌تر به او اعلام می‌شود، و روند مزایده روان‌تر پیش می‌رود.