Head First Software Architecture

توضیحات

کتاب Head First Software Architecture: A Learner’s Guide to Architectural Thinking نوشته‌ی Neal Ford، Mark Richards و Raju Gandhi یک مقدمه‌ی بصری و مغزپسند برای معماری نرم‌افزار است که در ژانویه ۲۰۲۴ توسط O’Reilly منتشر شد. این کتاب از همان نویسندگان Fundamentals of Software Architecture است، اما با رویکردی کاملاً متفاوت — به‌جای کتاب رفرنس جامع، یک on-ramp سریع و تعاملی برای توسعه‌دهندگانی است که می‌خواهند به سمت معماری حرکت کنند.
فرمت Head First با تصاویر فراوان، پازل، سوال‌های چالشی، و دیالوگ‌های فرضی بین شخصیت‌ها بر اساس تحقیقات علوم شناختی طراحی شده تا مطالب پیچیده را قابل جذب‌تر کند. چارچوب اصلی کتاب روی ۴ بُعد معماری بنا شده:

نظر

• امتیاز : 08/10
• به دیگران توصیه می‌کنم : بله
• دوباره می‌خوانم : خیر
• ایده برجسته : معماری نرم‌افزار یعنی مدیریت آگاهانه‌ی trade-off — هیچ سبک معماری کامل نیست و هر انتخاب چیزی را می‌دهد و چیزی را می‌گیرد؛ architect کسی است که این trade-offها را می‌بیند، می‌فهمد، و مستند می‌کند نه کسی که بهترین تکنولوژی را انتخاب می‌کند
• تاثیر در من : چارچوب ۴ بُعدی کتاب تبدیل به یک template ذهنی برای تحلیل هر سیستم شد — قبل از هر طراحی می‌توان پرسید: characteristics چیست؟ decisions کدامند؟ component boundaries کجاست؟ کدام style متناسب است؟ این چارچوب به‌خصوص در مباحث microservices و event-driven در .NET بسیار کاربردی است
• نکات مثبت : فرمت بصری که مفاهیم انتزاعی را ملموس می‌کند؛ سناریوهای kata که یادگیری فعال را ممکن می‌کند؛ پوشش سبک‌های مدرن مثل microservices و event-driven با مقایسه‌ی صادقانه‌ی trade-offها؛ مناسب هم برای مبتدی و هم برای مرور سیستماتیک senior developer؛ مکمل ایده‌آل برای Fundamentals of Software Architecture
• نکات منفی : عمق فنی پایین‌تر از Fundamentals of Software Architecture است — برای کسانی که آن را قبلاً خوانده‌اند مطالب تکراری خواهد بود؛ فرمت Head First برای برخی خوانندگان که رویکرد جدی‌تر ترجیح می‌دهند حواس‌پرت‌کننده است؛ معماری distributed systems و موضوعاتی مثل consensus، data consistency و CAP theorem پوشش داده نمی‌شود

مشخصات

• نویسنده :
  • Neal Ford
  • Mark Richards
  • Raju Gandhi
• انتشارات : O’Reilly Media
• صفحه مشخصات :

بخش‌هایی از کتاب

فصل اول: رازگشایی از معماری نرم‌افزار

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

چرا اصلاً به معماری نیاز داریم؟

نویسندگان کتاب برای تفهیم مفهوم معماری نرم‌افزار، از استعاره‌ی خانه استفاده می‌کنند. ساختار یک خانه—یعنی شکل کلی آن، تعداد اتاق‌ها و طبقات، و ابعادش—معماری آن خانه محسوب می‌شود، و این ساختار معمولاً از طریق یک نقشه‌ی ساختمانی (building plan) بازنمایی می‌شود که خطوط و کادرهای لازم برای ساخت خانه را در خود دارد.

نکته‌ی کلیدی اینجاست: ویژگی‌های ساختاری یک خانه پس از ساخت، به‌سختی قابل تغییر هستند و همین دلیل اهمیت بالای آن‌ها است. دقیقاً به همین شکل، معماری برای ساخت سیستم‌های نرم‌افزاری هم ضروری است. اگر تا به حال با سیستمی برخورد کرده باشید که مقیاس‌پذیر (scalable) نیست، قابل‌اعتماد (reliable) نیست، یا نگهداری‌اش دشوار است، به احتمال زیاد تأکید کافی روی معماری آن صورت نگرفته است.

معماری در برابر طراحی (Design)

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

به بیان دقیق‌تر نویسندگان: معماری کمتر درباره‌ی ظاهر و بیشتر درباره‌ی ساختار است؛ در حالی که طراحی برعکس آن، کمتر درباره‌ی ساختار و بیشتر درباره‌ی ظاهر است. برای مثال در یک وب‌سایت، معماری مربوط به این است که صفحات وب چگونه با سرویس‌های بک‌اند و پایگاه‌داده ارتباط برقرار می‌کنند تا داده را بازیابی یا ذخیره کنند؛ اما طراحی مربوط به این است که هر صفحه از نظر رنگ، چیدمان فیلدها و مانند آن چه ظاهری دارد.

این تمایز اهمیت عملی هم دارد: تصمیمات معماری معمولاً باید توسط معمار (architect) گرفته شوند، در حالی که تصمیمات طراحی می‌توانند بر عهده‌ی تیم توسعه باشند. البته بین این دو، یک طیف (spectrum) وجود دارد که بسیاری از تصمیمات واقعی جایی میان این دو سر طیف قرار می‌گیرند، نه دقیقاً در یکی از دو انتها.

---

چهار بُعد معماری نرم‌افزار

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

این چهار بُعد به شرح زیر است:

• ویژگی‌های معماری (Architectural Characteristics): جنبه‌هایی از سیستم که معماری باید از آن‌ها پشتیبانی کند—مانند مقیاس‌پذیری، تست‌پذیری و دسترس‌پذیری.
• تصمیمات معماری (Architectural Decisions): تصمیماتی با پیامدهای بلندمدت یا مهم برای سیستم، مانند نوع پایگاه‌داده، تعداد سرویس‌ها و نحوه‌ی ارتباط آن‌ها با یکدیگر.
• اجزای منطقی (Logical Components): بلوک‌های سازنده‌ی عملکردی سیستم و نحوه‌ی تعامل آن‌ها با هم، مانند اجزای مدیریت انبار یا پردازش پرداخت در یک سیستم تجارت الکترونیک.
• سبک معماری (Architectural Style): شکل و ساختار کلی فیزیکی سیستم نرم‌افزاری، شبیه به نقش نقشه‌ی ساختمانی برای خانه.

نکته‌ی مهمی که کتاب با لحن یک استاد سخت‌گیر بیان می‌کند این است: هیچ‌کدام از این چهار بُعد قابل صرف‌نظر نیست. در بخش «سؤالات بدون‌جواب نیستند» (There Are No Dumb Questions) به‌صراحت آمده که جمله‌ای مانند «معماری ما میکروسرویس است» تنها یک بُعد—سبک معماری—را توصیف می‌کند و بسیاری از سؤالات کلیدی را بی‌پاسخ می‌گذارد؛ مثلاً چه ویژگی‌هایی برای موفقیت سیستم حیاتی هستند؟ اجزای منطقی آن کدام‌اند؟ چه تصمیمات مهمی درباره‌ی نحوه‌ی پیاده‌سازی گرفته شده است؟

بُعد اول: ویژگی‌های معماری

این بُعد پایه‌ی اصلی معماری است؛ بدون آن نمی‌توانید تصمیمات معماری بگیرید یا تبادل‌های مهم (trade-offs) را تحلیل کنید. نویسندگان مثال زیبایی می‌زنند: فرض کنید بین دو خانه انتخاب می‌کنید—یکی بزرگ اما کنار بزرگراه شلوغ، و دیگری کوچک‌تر اما در محله‌ای آرام. بدون دانستن اینکه کدام ویژگی (اندازه یا آرامش) برای شما مهم‌تر است، نمی‌توانید انتخاب درست را انجام دهید.

همین منطق در انتخاب نوع پایگاه‌داده هم صادق است: انتخاب بین پایگاه‌داده‌ی رابطه‌ای، کلید-مقدار، یا گراف بستگی به این دارد که کدام ویژگی معماری برایتان حیاتی‌تر است—مثلاً پایگاه‌داده‌ی گراف برای سرعت بالای جست‌وجو (performance) یا پایگاه‌داده‌ی رابطه‌ای برای حفظ یکپارچگی داده (data integrity).

نکته‌ی اصطلاح‌شناسی مهم: این ویژگی‌ها با نام‌های دیگری هم شناخته می‌شوند—نیازمندی‌های غیرفانکشنال (non-functional requirements)، ویژگی‌های کیفیت سیستم (system quality attributes)، یا به‌طور خلاصه “the ilities” (چون بسیاری از آن‌ها با پسوند “-ility” تمام می‌شوند، مثل scalability، reliability). نویسندگان اما ترجیح می‌دهند از عبارت «ویژگی‌های معماری» استفاده کنند، چون این‌ها دقیقاً همان چیزی هستند که معماری باید از آن‌ها پشتیبانی کند.

بُعد دوم: تصمیمات معماری

تصمیمات معماری، انتخاب‌هایی درباره‌ی جنبه‌های ساختاری سیستم هستند که پیامدهای بلندمدت یا مهمی دارند و به‌عنوان قیدها (constraints) عمل می‌کنند و تیم توسعه را در برنامه‌ریزی و ساخت سیستم راهنمایی می‌کنند. مثال کتاب: تصمیم به اینکه لایه‌ی رابط کاربری نباید مستقیماً با پایگاه‌داده ارتباط برقرار کند، بلکه باید از طریق سرویس‌های زیرین داده را بازیابی و به‌روزرسانی کند—این یک تصمیم معماری است که هم قیدی روی توسعه‌ی UI می‌گذارد و هم راهنمایی برای بقیه‌ی اجزا فراهم می‌کند.

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

بُعد سوم: اجزای منطقی

اجزای منطقی، بلوک‌های سازنده‌ی سیستم هستند—دقیقاً مثل اتاق‌ها که بلوک‌های سازنده‌ی یک خانه‌اند. هر جزء منطقی یک وظیفه‌ی مشخص انجام می‌دهد، مثل پردازش پرداخت سفارش یا مدیریت انبار کالا. نکته‌ی فنی مهم اینجاست: در عمل، اجزای منطقی معمولاً از طریق دایرکتوری یا namespace بازنمایی می‌شوند؛ مثلاً دایرکتوری app/order/payment با namespace متناظر app.order.payment نشان‌دهنده‌ی جزء منطقی «پردازش پرداخت» است.

سؤال جالبی که در بخش «سؤالات بدون‌جواب نیستند» مطرح می‌شود، تفاوت بین دامنه (domain) و کارکرد سیستم (system functionality) است: دامنه یعنی «چه مسئله‌ای را حل می‌کنیم» (the what)، و کارکرد سیستم یعنی «چگونه آن را حل می‌کنیم» (the how).

بُعد چهارم: سبک معماری

همان‌طور که خانه‌ها سبک‌های متفاوتی دارند (ویکتوریایی، رنچ، تئودور)، سیستم‌های نرم‌افزاری هم سبک‌های معماری متفاوتی دارند که هر کدام مجموعه‌ای منحصربه‌فرد از ویژگی‌ها را ارائه می‌دهند. برای نمونه، سبک میکروسرویس مقیاس‌پذیری بالا و agility (توانایی پاسخ سریع به تغییر) را فراهم می‌کند، در حالی که سبک لایه‌ای (layered) پیچیدگی و هزینه‌ی کمتری دارد، و سبک event-driven سرعت و مقیاس‌پذیری بالایی ارائه می‌دهد.

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

درهم‌تنیدگی چهار بُعد

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

---

طیف بین معماری و طراحی

پس از معرفی چهار بُعد معماری، کتاب به یکی از پرکاربردترین ابزارهای عملی این فصل می‌پردازد: چگونه تشخیص دهیم یک تصمیم، معماری است یا طراحی؟ نویسندگان تصریح می‌کنند که بعضی تصمیمات قطعاً معماری‌اند (مثل انتخاب سبک معماری) و بعضی دیگر قطعاً طراحی‌اند (مثل تغییر جای یک فیلد در صفحه)، اما اکثر تصمیمات جایی میان این دو، در یک طیف (spectrum) قرار می‌گیرند.

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

کتاب سه معیار مشخص برای تعیین موقعیت یک تصمیم روی این طیف معرفی می‌کند:

معیار اول: استراتژیک یا تاکتیکی؟

تصمیمات استراتژیک بلندمدت‌اند و بر اقدامات و تصمیمات آینده تأثیر می‌گذارند، در حالی که تصمیمات تاکتیکی کوتاه‌مدت‌اند و معمولاً مستقل از سایر اقدامات باقی می‌مانند (هرچند ممکن است در بستر یک استراتژی خاص قرار گیرند). هرچه تصمیمی استراتژیک‌تر باشد، بیشتر به سمت معماری متمایل می‌شود.

برای تشخیص استراتژیک بودن یک تصمیم، کتاب سه پرسش راهنما ارائه می‌دهد:

• چقدر فکر و برنامه‌ریزی برای این تصمیم لازم است؟ اگر چند دقیقه تا یک ساعت زمان می‌برد، تاکتیکی است؛ اگر چند روز یا چند هفته برنامه‌ریزی لازم دارد، احتمالاً استراتژیک (و معماری) است.
• چند نفر در این تصمیم دخیل‌اند؟ هرچه افراد بیشتری درگیر باشند، تصمیم استراتژیک‌تر است. تصمیمی که خودتان یا با یک همکار می‌گیرید تاکتیکی است؛ تصمیمی که نیاز به جلسات متعدد با ذی‌نفعان دارد، استراتژیک است.
• آیا تصمیم شما یک چشم‌انداز بلندمدت را دربر می‌گیرد یا یک اقدام کوتاه‌مدت؟ اگر تصمیمی موقتی و به‌زودی قابل تغییر است، تاکتیکی (طراحی) است؛ اگر با آن برای مدت طولانی زندگی خواهید کرد، استراتژیک (معماری) است.

معیار دوم: میزان تلاش برای ساخت یا تغییر

نویسندگان به نقل مشهور مارتین فاولر اشاره می‌کنند که «معماری نرم‌افزار همان چیزی است که تغییرش سخت است». بر همین اساس، هرچه تغییر یک تصمیم در آینده سخت‌تر باشد، بیشتر به سمت معماری متمایل می‌شود؛ و هرچه راحت‌تر قابل تغییر باشد، بیشتر به سمت طراحی می‌رود.

مثال کتاب: مهاجرت از معماری لایه‌ای n-tier سنتی به میکروسرویس، تلاش و زمان زیادی می‌طلبد، پس در انتهای دور معماری طیف قرار دارد. در مقابل، جابه‌جایی فیلدها در یک صفحه‌ی رابط کاربری تلاش نسبتاً کمی می‌طلبد و در انتهای دور طراحی قرار می‌گیرد.

معیار سوم: اهمیت تبادل‌ها (Trade-offs)

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

ترکیب سه معیار در یک مثال عملی

کتاب این سه معیار را در یک مثال واقعی به کار می‌گیرد: تصمیم به استفاده از messaging غیرهمزمان (asynchronous) بین سرویس Order Placement و سرویس Inventory Management برای افزایش پاسخ‌گویی سیستم هنگام ثبت سفارش. این نوع تحلیل به شما یاد می‌دهد که چگونه سه معیار بالا را روی یک تصمیم واقعی پیاده کنید تا بفهمید در کجای طیف قرار می‌گیرد.

نکات کلیدی فصل اول (Bullet Points)

کتاب در پایان فصل، نکات محوری را این‌گونه جمع‌بندی می‌کند:

• معماری کمتر درباره‌ی ظاهر و بیشتر درباره‌ی ساختار است؛ طراحی برعکس این است.
• برای درک و توصیف معماری نرم‌افزار باید از چهار بُعد استفاده کرد: ویژگی‌های معماری، تصمیمات معماری، اجزای منطقی و سبک معماری.
• ویژگی‌های معماری، بنیان معماری را می‌سازند و باید بدانید کدام ویژگی برای سیستم شما مهم‌ترین است تا بتوانید تبادل‌ها را تحلیل و تصمیمات درست را بگیرید.
• تصمیمات معماری، راهنمای ساختاری تیم‌های توسعه‌اند.
• اجزای منطقی، بلوک‌های سازنده‌ی سیستم‌اند و از طریق فایل‌های کلاس یا کد منبع پیاده‌سازی می‌شوند.
• هر سبک معماری از مجموعه‌ای خاص از ویژگی‌ها پشتیبانی می‌کند، پس انتخاب سبک درست اهمیت زیادی دارد.
• دانستن اینکه یک تصمیم معماری است یا طراحی، تعیین می‌کند چه کسی مسئول آن تصمیم است و چقدر اهمیت دارد.

با این بخش، فصل اول کتاب به پایان می‌رسد. فصل دوم با عنوان «ویژگی‌های معماری: قرار دادن Function در Non-functional» آغاز می‌شود که به بررسی عمیق‌تر ویژگی‌های معماری می‌پردازد.

---

فصل دوم: ویژگی‌های معماری، تابعِ Function در Nonfunctional

فصل دوم با یک سؤال بنیادین شروع می‌شود: چرا اصلاً باید به چیزی به نام «غیرفانکشنال» (non-functional) اهمیت دهیم؟ نویسندگان تصریح می‌کنند که یک معمار سیستم را برای برآوردن نیازمندی‌ها طراحی می‌کند، اما عوامل دیگری هم بر طراحی تأثیر می‌گذارند—عواملی که به قابلیت‌های سیستم مربوط‌اند، نه صرفاً رفتار آن. برای مثال، اگر سیستمی باید تعداد زیادی کاربر همزمان را پشتیبانی کند و در این کار ناکام بماند، آن سیستم موفق نیست، هرچند از نظر رفتاری درست کار کند.

داستان Laffter: زمینه‌ی تمرینی فصل

کتاب برای تدریس این مفاهیم یک مطالعه‌ی موردی طراحی می‌کند: Sillycon Symposia، یک استارتاپ که کنفرانس‌های فناوری را با کمدی ترکیب می‌کند و می‌خواهد شبکه‌ی اجتماعی‌ای به نام Laffter بسازد. در یک گفت‌وگوی کوبیکل (Cubicle Conversation)، شخصیت Sam به Mara و Alex یادآوری می‌کند که نمی‌توان مستقیماً وارد طراحی سیستم شد؛ ابتدا باید ویژگی‌های معماری و اجزای منطقی را تحلیل کرد، چون رویکرد تکرارگرا (iterative) برای تحلیل ویژگی‌های معماری کار نمی‌کند—مثلاً نمی‌توان سیستمی را که از ابتدا برای مقیاس‌پذیری بالا طراحی نشده، بعداً به‌سادگی مقیاس‌پذیر کرد.

چرا اصطلاح «نیازمندی غیرفانکشنال» گمراه‌کننده است

کتاب در بخش «SERIOUS CODING» صریحاً با نام‌گذاری رایج مخالفت می‌کند و این را یک جای بحث آکادمیک مهم می‌داند نه صرفاً سلیقه‌ای:

• نیازمندی غیرفانکشنال (non-functional requirement): اصطلاح رایج اما گمراه‌کننده، چون ویژگی‌های معماری در واقع فانکشنال هستند—فقط به دامنه (domain) مربوط نمی‌شوند. نامیدنشان «غیرفانکشنال» اهمیتشان را کم‌رنگ می‌کند.
• ویژگی‌های کیفیت سیستم (system quality attributes): این اصطلاح به‌اشتباه القا می‌کند که این‌ها فعالیتی در پایان پروژه‌اند، نه از ابتدای آن.
• نیازمندی‌های cross-cutting: کتاب این را کم‌آسیب‌ترین می‌داند اما همچنان به خاطر کلمه‌ی «requirement» آن را ترجیح نمی‌دهد، چون این کلمه ویژگی‌های معماری را با رفتار دامنه درهم می‌آمیزد.

تعریف سه‌بخشی ویژگی‌های معماری

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

بخش اول: یک ملاحظه‌ی طراحی غیر-دامنه‌ای نیازمندی‌ها می‌گویند سیستم باید چه کاری انجام دهد؛ ویژگی‌های معماری معیارهای عملیاتی و طراحی موفقیت را مشخص می‌کنند—یعنی چگونه نیازمندی‌ها پیاده‌سازی شوند و چرا انتخاب‌های خاصی صورت گرفته‌اند. برای نمونه، سطح performance یک ویژگی معماری مهم است که معمولاً در سند نیازمندی‌ها ذکر نمی‌شود؛ حتی هیچ سند نیازمندی به شما نمی‌گوید «از تکنیکال‌دبت (technical debt) پیشگیری کن»، اما این همچنان یک ملاحظه‌ی طراحی رایج برای معماران است.

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

بخش سوم: اهمیت (important) سیستم‌ها می‌توانند به‌طور بالقوه از تعداد بسیار زیادی ویژگی معماری پشتیبانی کنند، اما نباید این کار را بکنند. هر ویژگی معماری‌ای که سیستم باید پشتیبانی کند، پیچیدگی بیشتری به طراحی اضافه می‌کند؛ بنابراین معماران باید تلاش کنند کمترین تعداد ممکن ویژگی معماری را انتخاب کنند، نه بیشترین. کتاب سه دلیل برای این محدودیت ارائه می‌دهد:

• غیرقابل استانداردسازی: سازمان‌های مختلف اصطلاحات متفاوتی برای همان ویژگی به کار می‌برند (مثلاً performance و responsiveness ممکن است یک رفتار را نشان دهند).
• هم‌افزا (synergistic): ویژگی‌های معماری روی هم و روی دامنه تأثیر می‌گذارند؛ مثلاً افزایش امنیت معمولاً performance را کاهش می‌دهد.
• پرشمار (overabundant): تعداد ویژگی‌های ممکن فوق‌العاده زیاد است و مدام در حال افزایش (مثل on-demand elasticity که چند سال پیش وجود نداشت).

نکته‌ی هشدارآمیز کتاب این است که این هم‌افزایی می‌تواند خطرناک باشد: هیچ معماری‌ای نمی‌تواند برای همه‌ی ویژگی‌ها به‌طور مستقل طراحی شود؛ تغییر در یک بخش دامنه (مثلاً افزودن ذخیره‌سازی اطلاعات پرداخت کاربران) به‌طور خودکار ویژگی‌های امنیت و یکپارچگی داده را نیز تغییر می‌دهد. کتاب همچنین به خطر overengineering اشاره می‌کند: افزودن ویژگی‌های معماری بیش از حد نیاز، که کتاب با طعنه آن را «RDD—Resume-Driven Development» می‌نامد.

---

ویژگی‌های صریح و ضمنی

بخش بعدی فصل دوم به یکی از تمایزهای کاربردی‌ترین کتاب می‌پردازد: تفاوت بین ویژگی‌های صریح (explicit) و ضمنی (implicit). ویژگی‌های صریح آن‌هایی هستند که مستقیماً در سند نیازمندی‌ها ذکر شده‌اند؛ اما ویژگی‌های ضمنی، عواملی هستند که بر تصمیم معمار تأثیر می‌گذارند بدون آنکه در نیازمندی‌ها به‌صراحت آمده باشند.

نویسندگان امنیت را نمونه‌ی کلاسیک یک ویژگی ضمنی می‌دانند: حتی اگر در نیازمندی‌ها ذکر نشود، معماران می‌دانند که نباید سیستمی ناامن طراحی کنند. مثال جالب‌تر: یک شرکت معاملات با فرکانس بالا (high-frequency trading) ممکن است در سند نیازمندی‌ها هرگز نگوید که تراکنش‌ها باید در چند میلی‌ثانیه تکمیل شوند، اما معماران آن حوزه به‌خوبی می‌دانند این نکته چقدر حیاتی است. کتاب همچنین هشدار می‌دهد که برخی ویژگی‌های ضمنی بسیار ظریف‌تر هستند، مثل حفظ ماژولاریتی داخلی کد در طول توسعه—چیزی که هیچ‌گاه در فهرست نیازمندی‌ها نوشته نمی‌شود، اما معماران باید مراقب آن باشند.

باغ‌وحش بین‌المللی «-ility»ها

با طعنه‌ی مشخص سبک Head First، نویسندگان ویژگی‌های معماری را با حیوانات یک باغ‌وحش مقایسه می‌کنند و آن‌ها را در چهار دسته‌ی اصلی سازمان می‌دهند:

دسته	تعریف	نمونه‌ها
Process (فرایندی)	تلاقی فرایند توسعه با معماری	testability، deployability، configurability
Structural (ساختاری)	تأثیر روی ساختار داخلی سیستم	security، extensibility، maintainability، portability، localization
Operational (عملیاتی)	تأثیر تصمیمات معماری روی تیم عملیات	availability، robustness، reliability/safety، recoverability، performance، scalability
Cross-cutting (میان‌بخشی)	ویژگی‌هایی که دسته‌بندی مشخصی ندارند	authentication/authorization، accessibility، legal، privacy، usability

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

منابع کشف ویژگی‌های معماری

کتاب سه منبع اصلی برای کشف ویژگی‌های معماری معرفی می‌کند:

• دامنه‌ی مسئله (problem domain): بیشتر ویژگی‌ها از ترجمه‌ی نیازمندی‌ها به‌دست می‌آیند؛ مثلاً «هزاران کاربر» در نیازمندی‌ها باید به scalability، concurrency و elasticity ترجمه شود.
• آگاهی محیطی (environmental awareness): ویژگی‌های ضمنی که از شناخت کلی سازمان می‌آیند؛ مثلاً یک استارتاپ سریع‌الحرکت طبیعتاً به agility اولویت می‌دهد، حتی اگر ذکر نشده باشد.
• دانش کلی دامنه (holistic domain knowledge): دانشی که به‌صراحت در نیازمندی‌ها نیامده اما معمار از تجربه‌ی خود می‌داند؛ مثال دانشگاه با ثبت‌نام دانشجویان که به دلیل رفتار واقعی کاربران (برخی زودهنگام و برخی تعلل‌کننده)، به‌جای بار یکنواخت، نیاز به طراحی برای ترافیک انفجاری (elastic burst) در ابتدا و انتهای بازه‌ی ثبت‌نام دارد.

نکته‌ی بسیار مهم دیگر، تفکیک راه‌حل از مسئله (solution versus problem) است. کاربران معمولاً به‌جای نیازمندی، راه‌حل پیشنهاد می‌دهند. کتاب داستان واقعی طراحی جت F-16 را مثال می‌زند: نیروی هوایی آمریکا خواسته بود جتی با سرعت ماخ ۲.۵ بسازند، اما وقتی طراحان پرسیدند «چرا؟»، معلوم شد هدف اصلی توانایی فرار از درگیری بوده—و نتیجه، F-16 با سرعت کمتر (ماخ ۲.۱) اما مانورپذیری و شتاب فوق‌العاده بود. درس این داستان برای معماران: باید مثل یک کودک کنجکاو مدام بپرسید «چرا؟» تا نیازمندی واقعی پشت یک راه‌حل پیشنهادی را کشف کنید.

ویژگی‌های ترکیبی و عدد جادویی هفت

نویسندگان مفهوم ویژگی‌های ترکیبی (composite) را معرفی می‌کنند: ترکیبی از دو یا چند ویژگی که ویژگی جدیدی به‌نظر می‌رسد؛ مثلاً «reliability» ترکیبی از availability، ثبات UI و یکپارچگی داده است. معیار تشخیص یک ویژگی ترکیبی این پرسش است: «آیا می‌توانم این را عینی و قابل‌اندازه‌گیری کنم؟» performance نمونه‌ی خوبی است—چون به‌تنهایی قابل‌اندازه‌گیری نیست، مگر آن را به معیارهای دقیق‌تری مثل first contentful paint تجزیه کنیم.

در پایان، کتاب راهکار عملی «عدد جادویی هفت» را ارائه می‌دهد، بر اساس مقاله‌ی معروف روانشناس جورج میلر (۱۹۵۶) که نشان می‌دهد انسان‌ها اطلاعات را در بلوک‌های هفتایی بهتر به خاطر می‌سپارند. توصیه‌ی نویسندگان: معماران باید تعداد ویژگی‌های معماری انتخابی را به حدود هفت مورد محدود کنند تا از overengineering پیشگیری شود، و سه مورد از آن‌ها را به‌عنوان ویژگی‌های محرک (driving characteristics) اولویت‌بندی کنند.

---

فصل سوم: دو قانون معماری نرم‌افزار

فصل سوم با یک نکته‌ی تلخ اما واقعی شروع می‌شود: برخلاف بسیاری از حوزه‌های مهندسی، معماری نرم‌افزار best practice ندارد. باید هر وضعیت را با دقت تحلیل کرد و نه‌فقط «چه تصمیمی گرفته شد»، بلکه «چرا آن تصمیم گرفته شد» را هم مستند کرد. برای هدایت در این فضای نامعین، کتاب دو قانون بنیادین معرفی می‌کند.

داستان زمینه: اپلیکیشن Two Many Sneakers

کتاب مثال Two Many Sneakers را مطرح می‌کند؛ اپلیکیشنی برای خریدوفروش کفش‌های کلکسیونی که در ابتدا با یک سرویس ساده (trading service) کار می‌کرد. با رشد کسب‌وکار، مشتریان اعلان لحظه‌ای (real-time notification) خواستند و تیم مدیریت هم تشخیص تقلب (fraud detection) را در اولویت گذاشت. راه‌حل اولیه این بود: سرویس trading باید سرویس‌های notification و analytics را از طریق messaging مطلع کند.

قانون اول: همه‌چیز یک تبادل (Trade-off) است

پیش از این در فصل ۱ درباره‌ی تبادل‌های چشمگیر و کم‌اهمیت صحبت شد؛ اکنون کتاب این را به‌عنوان قانون اول معماری نرم‌افزار رسمیت می‌بخشد: هر تصمیمی که بگیرید، مزایا و معایبی دارد و نمی‌توانید همه‌چیز را همزمان به حداکثر برسانید. نویسندگان از ریچ هیکی، خالق زبان Clojure، نقل می‌کنند: «برنامه‌نویسان مزایای همه‌چیز را می‌دانند و تبادل‌های هیچ‌چیز را نمی‌دانند»؛ و اضافه می‌کنند که معماران باید هر دو را بشناسند.

مثال عملی این قانون، انتخاب بین دو مدل messaging است:

مکانیزم	مزایا	معایب
Queue (نقطه‌به‌نقطه)	امنیت بالاتر (publisher می‌داند چه کسی گوش می‌دهد)، امکان پیام‌های اختصاصی برای هر مصرف‌کننده، مقیاس‌پذیری مستقل هر صف
Topic (پخش‌محور)	Coupling پایین؛ سرویس‌های جدید بدون تغییر در publisher می‌توانند subscribe کنند

نکته‌ی کلیدی که کتاب تأکید می‌کند: باید بدانید کدام ویژگی معماری برایتان مهم‌تر است، سپس راه‌حلی انتخاب کنید که بهترین پشتیبانی را از آن ویژگی‌ها ارائه دهد—نه راه‌حلی که «کامل» باشد، چون چنین راه‌حلی وجود ندارد.

قانون دوم: چرایی مهم‌تر از چگونگی است

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

ابزار عملی: Architectural Decision Records (ADR)

برای رعایت قانون دوم، کتاب ADR را معرفی می‌کند: سندی که هر تصمیم معماری را با دلیل آن ثبت می‌کند. یک ADR از هفت بخش تشکیل شده:

• Title: عنوانی مختصر و اسم‌محور، با پیشوند عددی سه‌رقمی (مثل 001، 012) برای ترتیب‌بندی.
• Status: وضعیت تصمیم (مثلاً Accepted). اگر تصمیمی بعداً با تصمیم دیگری جایگزین شود، ADR قدیمی وضعیت Superseded می‌گیرد و ADR جدید Accepted می‌شود.
• Context: توضیح می‌دهد چرا این تصمیم اصلاً لازم بود.
• Decision: خودِ تصمیم را با توجیه ثبت می‌کند و همیشه باید «چرا» را در بر بگیرد.
• Consequences: پیامدهای مثبت و منفی مورد انتظار تصمیم را توصیف می‌کند.
• Governance: راه‌هایی برای اطمینان از اجرای صحیح تصمیم فهرست می‌کند.
• Notes: فراداده‌هایی مثل نویسنده و تاریخ‌های تصویب و آخرین ویرایش.

مثال عملی از کتاب برای تیم Two Many Sneakers: عنوان ADR دوازدهم آن‌ها می‌شود «012: استفاده از queue برای messaging غیرهمزمان بین سرویس‌های سفارش و پایین‌دستی». بخش Decision این ADR توضیح می‌دهد که چرا queue انتخاب شد: چون امکان پیام‌های ناهمگون (heterogeneous) را می‌دهد و چون trading service دقیقاً می‌داند چه کسی subscribe کرده، امنیت سیستم را بهبود می‌بخشد.

نکته‌ی مهم دیگر: ADRها با گذر زمان به یک گزارش تصمیمات معماری (decision log) تبدیل می‌شوند که حافظه‌ی نهادی (institutional knowledge) پروژه را می‌سازد و به تیم‌ها اجازه می‌دهد از تجربه‌ی یکدیگر بیاموزند.

---

فصل چهارم: اجزای منطقی سیستم

فصل چهارم به بعد دوم تحلیل ساختاری معماری می‌پردازد: اجزای منطقی (logical components)، یعنی بلوک‌های سازنده‌ی سیستم که دامنه‌ی کسب‌وکار را نمایندگی می‌کنند. برخلاف ویژگی‌های معماری که مستقل از دامنه هستند، اجزای منطقی همان چیزهایی‌اند که سیستم واقعاً «انجام می‌دهد» و معمولاً از طریق ساختار دایرکتوری یا namespace در کد پیاده‌سازی می‌شوند.

فرایند چهارگانه‌ی طراحی معماری منطقی

کتاب یک فلوچارت مداوم برای ساخت معماری منطقی معرفی می‌کند که تا پایان عمر سیستم تکرار می‌شود:

1. شناسایی اجزای اصلی اولیه (initial core components)
2. تخصیص نیازمندی‌ها به اجزا
3. تحلیل مسئولیت‌های هر جزء
4. تحلیل ویژگی‌های معماری مرتبط با هر جزء

نکته‌ی کلیدی این بخش این است که شناسایی اجزا در ابتدا یک «بازی حدس زدن» است؛ نباید نگران اندازه‌ی دقیق اجزا در ابتدای کار بود، چون با یادگیری بیشتر درباره‌ی سیستم، بازآرایی (refactor) اجتناب‌ناپذیر است.

دو رویکرد درست برای شناسایی اجزا

رویکرد	روش کار	بهترین کاربرد
Workflow approach	با دنبال‌کردن مراحل اصلی سفر کاربر در سیستم، هر مرحله را به یک جزء نگاشت می‌کند	سیستم‌های با سفرهای پیچیده‌ی کاربری
Actor/Action approach	ابتدا بازیگران (actors) سیستم شناسایی می‌شوند، سپس اقدامات اصلی هر بازیگر به جزء موجود یا جدید تخصیص می‌یابد	سیستم‌های با انواع متعدد کاربر

نویسندگان تصریح می‌کنند این دو رویکرد قابل ترکیب هستند: می‌توان با actor/action اقدامات را شناسایی کرد و سپس با workflow ترتیب وقوع آن‌ها را مشخص کرد. کتاب همچنین actor/action approach را با تکنیک event storming در حوزه‌ی domain-driven design مقایسه می‌کند و توضیح می‌دهد که event storming عمیق‌تر پیش می‌رود و عناصری مثل command، aggregate و view را نیز در بر می‌گیرد.

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

کتاب یک ضدالگو (anti-pattern) رایج را با عنوان entity trap هشدار می‌دهد: تخصیص یک جزء به هر موجودیت اصلی سیستم (مثل Auction Manager، Item Manager). این رویکرد دو مشکل جدی ایجاد می‌کند:

• نام‌های اجزا بیش‌ازحد کلی و مبهم می‌شوند (چه فرقی دارد «Auction Manager» با کل سیستم؟)
• اجزا به سطل زباله‌ای برای هر عملکرد مرتبط تبدیل می‌شوند و مسئولیت‌های بیش‌ازحد زیادی می‌گیرند، که نگهداری آن‌ها را دشوار می‌کند

نشانه‌ی هشداردهنده‌ی افتادن در این تله، استفاده‌ی مکرر از کلماتی مثل «Manager»، «Supervisor» یا «Handler» در نام‌گذاری اجزا است، مگر آنکه واقعاً یک وظیفه‌ی عمومی و مشخص را توصیف کنند (مثل «Reference Data Manager»).

Coupling: چسبندگی بین اجزا

بخش پایانی فصل به coupling (وابستگی بین اجزا) می‌پردازد که به دو نوع تقسیم می‌شود:

• Afferent coupling (ورودی): زمانی که اجزای دیگر به یک جزء هدف وابسته‌اند.
• Efferent coupling (خروجی): زمانی که یک جزء هدف به اجزای دیگر وابسته است.

هر دو نوع، اشکالی از static coupling هستند و هرچه جزء بیشتر درباره‌ی «چگونگی» کار سیستم بداند، coupling آن بالاتر می‌رود. کتاب قانون دیمیتر (Law of Demeter)، معروف به «اصل کمترین دانش»، را ابزاری برای کاهش coupling معرفی می‌کند، اما هشدار مهمی هم می‌دهد: کاهش coupling در واقع دانش گردش‌کار (workflow knowledge) را در سراسر سیستم توزیع می‌کند، که مدیریت و کنترل آن را دشوارتر می‌سازد—یعنی این هم یک تبادل (trade-off) دیگر است، نه یک راه‌حل بدون هزینه. در تمرین پایانی فصل، سطح کل coupling یک معماری منطقی نمونه محاسبه شده و عدد ۱۸ به‌عنوان سطحی بالا ارزیابی می‌شود.

---

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

تله‌ی موجودیت با مثال دقیق

فرض کنید سیستمی برای یک حراجی آنلاین (auction system) طراحی می‌کنید. رویکرد اشتباه (entity trap) این است که به ازای هر اسم مهم در دامنه، یک جزء بسازید:

• Auction Manager — برای مدیریت حراجی‌ها
• Item Manager — برای مدیریت کالاها
• Bid Manager — برای مدیریت پیشنهادها

مشکل این‌جاست: وقتی می‌پرسید «Auction Manager دقیقاً چه کاری انجام می‌دهد؟»، پاسخ چیزی شبیه «همه‌ی کارهای مربوط به حراجی» است. یعنی این جزء عملاً هر منطقی را که به کلمه‌ی «Auction» ربط داشته باشد در خود جذب می‌کند—از ایجاد حراجی، تا بستن آن، تا محاسبه‌ی قیمت نهایی، تا اعلان به برندگان. نتیجه، جزئی می‌شود که مسئولیت‌های نامرتبط و بی‌شماری دارد و در عمل تبدیل به یک مینی‌مونولیت داخل معماری منطقی می‌شود.

راه‌حل درست، تجزیه‌ی این «مدیران» بر اساس رفتار واقعی و مجزا است، نه بر اساس اسم موجودیت. به‌جای یک Auction Manager بزرگ، ممکن است به اجزایی مثل Auction Scheduling، Auction Closing، و Winner Notification برسید که هرکدام یک مسئولیت مشخص و قابل توصیف در یک جمله دارند.

نشانه‌ی هشدار: اگر در نام‌گذاری اجزای خود مدام از کلمات Manager، Supervisor یا Handler استفاده می‌کنید، احتمالاً در تله افتاده‌اید—مگر اینکه آن کلمه واقعاً یک وظیفه‌ی عمومی و محدود را توصیف کند (مثل Reference Data Manager که فقط داده‌های مرجع ثابت را نگه می‌دارد).

تفاوت دو رویکرد شناسایی جزء با مثال

برای یک سیستم فرضی رزرو بلیط سینما، دو رویکرد این‌طور عمل می‌کنند:

Workflow approach: مسیر واقعی کاربر را دنبال می‌کنید: کاربر فیلم را جست‌وجو می‌کند → سانس را انتخاب می‌کند → صندلی را انتخاب می‌کند → پرداخت می‌کند → بلیط دریافت می‌کند. هر گام به یک جزء بالقوه نگاشت می‌شود (Movie Search، Seat Selection، Payment Processing، Ticket Issuance).

Actor/Action approach: ابتدا بازیگران را می‌شناسید (Customer، Theater Staff، Payment Gateway)، سپس برای هر بازیگر اقدامات ممکن را فهرست می‌کنید. مثلاً Customer می‌تواند: جست‌وجو کند، صندلی انتخاب کند، پرداخت کند، بلیط را لغو کند. سپس هر اقدام به یک جزء موجود تخصیص می‌یابد یا در صورت نیاز جزء جدیدی ساخته می‌شود.

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

Coupling با مثال عددی

کتاب coupling را با شمارش وابستگی‌های بین اجزا می‌سنجد. تصور کنید سه جزء دارید: Order Placement، Inventory Management و Payment Processing:

• اگر Order Placement برای ثبت سفارش به Inventory Management (برای چک موجودی) و به Payment Processing (برای پرداخت) نیاز داشته باشد، Order Placement دارای efferent coupling برابر ۲ است (به دو جزء دیگر وابسته است).
• در همان حال، Inventory Management چون توسط Order Placement صدا زده می‌شود، دارای afferent coupling برابر ۱ است (یک جزء دیگر به آن وابسته است).

برای محاسبه‌ی سطح کلی coupling یک معماری منطقی، تمام این وابستگی‌های ورودی و خروجی را در سراسر نمودار جمع می‌زنید. در تمرین پایانی فصل، سیستم نمونه‌ی کتاب عدد ۱۸ را برای این جمع به‌دست می‌آورد که به‌عنوان سطح بالا ارزیابی می‌شود. عدد بالاتر یعنی اجزا به‌شدت به یکدیگر گره خورده‌اند و تغییر در یک جزء به‌احتمال زیاد اجزای دیگر را هم تحت تأثیر قرار می‌دهد—دقیقاً همان چیزی که قانون دیمیتر (Law of Demeter) تلاش می‌کند کاهش دهد، هرچند با هزینه‌ی پخش‌شدن دانش گردش‌کار در سطح سیستم.

---

مثال کامل Adventurous Auctions

خب، حالا با متن دقیق کتاب می‌توانم مثال واقعی و کامل «Adventurous Auctions» (سیستم حراجی سفرهای ماجراجویانه) را برایتان باز کنم که خودِ کتاب هم دقیقاً همین سناریو را برای توضیح تخصیص ویژگی‌های معماری به اجزا استفاده می‌کند.

تحلیل جزء Bid Capture

سیستم Adventurous Auctions جزئی به نام Bid Capture دارد که در ابتدا سه مسئولیت داشت:

1. دریافت پیشنهادها (bids) از کاربران آنلاین و از حراج‌گزار برای شرکت‌کنندگان حضوری
2. تشخیص اینکه کدام پیشنهاد آنلاین بالاترین است
3. نوشتن همه‌ی پیشنهادها در پایگاه‌داده Bid Tracking برای ردیابی

سه ویژگی معماری حیاتی برای موفقیت این سیستم شناسایی شدند:

• Scalability: سیستم باید هزاران پیشنهاددهنده در ثانیه را پشتیبانی کند
• Availability: سیستم باید در طول برگزاری حراجی‌ها همواره فعال باشد
• Performance: سیستم باید پیشنهاد را بگیرد و در سریع‌ترین زمان ممکن به حراج‌گزار برساند

کشف مشکل با تحلیل تک‌تک ویژگی‌ها

وقتی این سه ویژگی را روی Bid Capture پیاده کردید، مشکل آشکار می‌شود: مسئولیت سوم (نوشتن در دیتابیس) هر سه ویژگی حیاتی را تخریب می‌کند:

• Scalability آسیب می‌بیند چون اتصالات و throughput دیتابیس محدود است
• Performance آسیب می‌بیند چون نوشتن در دیتابیس زمان انتظار اضافه می‌کند
• Availability آسیب می‌بیند چون اگر دیتابیس از کار بیفتد، کل جزء متوقف می‌شود

راه‌حل: شکستن جزء

راه‌حل کتاب این است که مسئولیت سوم را به جزء جدیدی به نام Bid Tracker منتقل کنید. حالا Bid Capture فقط پیشنهاد را می‌گیرد و به Bid Tracker می‌فرستد، بدون آنکه منتظر نوشتن در دیتابیس بماند. نتیجه: scalability، performance و availability هر سه به‌طور چشمگیری بهبود می‌یابند، چون Bid Capture دیگر به دیتابیس گره نخورده است.

نکته‌ی درس‌آموز کتاب: گاهی باید یک جزء را بشکنید یا ترکیب کنید، دقیقاً بر اساس ویژگی‌های معماری مورد نیاز — این دقیقاً همان گام چهارم از فرایند چهارگانه‌ای است که قبلاً معرفی شد.

Coupling با اعداد واقعی کتاب

حالا با مثال دقیق افعرنت و افرنت کاپلینگ:

Afferent coupling (مثال Bidder Profile): دو جزء دیگر—Auction Registration و Auto Payment—هر دو برای گرفتن اطلاعات پروفایل به جزء Bidder Profile وابسته‌اند. بنابراین Bidder Profile سطح afferent coupling برابر ۲ دارد (نمادش CA). کتاب هشدار می‌دهد: اگر afferent coupling زیاد باشد، احتمالاً اجزا را بیش‌ازحد ریزدانه (fine-grained) طراحی کرده‌اید و باید آن‌ها را ترکیب کنید.

Efferent coupling (مثال Bid Capture): در فرایند پذیرش یک پیشنهاد، جزء Bid Capture به دو جزء دیگر—Bid Streamer و Bid Tracker—وابسته است تا پیشنهاد را پردازش کند. بنابراین Bid Capture سطح efferent coupling برابر ۲ دارد (نمادش CE).

Total coupling: برای هر جزء، (C_T = C_A + C_E). با جمع این مقدار برای همه‌ی اجزای یک معماری منطقی، عدد کل coupling سیستم به‌دست می‌آید که در تمرین کتاب برابر ۱۸ محاسبه شده و به‌عنوان سطح بالا ارزیابی می‌شود.

نکته‌ی کاربردی: اگر یک جزء afferent coupling بالایی دارد (مثل Bidder Profile با CA=2)، تغییر در آن جزء می‌تواند روی هر دو جزء وابسته (Auction Registration و Auto Payment) اثر بگذارد—یعنی ویژگی‌هایی مثل reliability و maintainability آن دو جزء هم تحت تأثیر قرار می‌گیرد.

---