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

ویژگی‌های معماری: توانایی‌هات رو بشناس

معماری‌ات باید از چه چیزهایی پشتیبانی کنه؟

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

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

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

تقریباً می‌تونی هر نوع برنامه‌ای رو با هر سبک معماری پیاده‌سازی کنی، ولی بعضی سبک‌ها برای بعضی پروژه‌ها مناسب‌ترن. اینکه بدون این تحلیل‌ها سبک معماری رو انتخاب کنی، مثل اینه که گاری رو جلوتر از اسب بذاری.

ویژگی‌های معماری چی هستن؟

فرض کن با یه مشکل روبه‌رو شدی و تصمیم گرفتی: “می‌خوام یه نرم‌افزار بنویسم تا این مشکل رو حل کنم!” اون چیزی که نرم‌افزار قراره درباره‌ش باشه، می‌شه دامین (domain)، و طراحی برای اون بخش زیادی از انرژی‌تو می‌گیره—چون اصل ماجرا همینه.

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

مقایسه‌ای بین ویژگی‌های معماری مورد نیاز برای بانک‌ها و سایت‌های مزایده آنلاین

بانک‌ها:

• قابلیت حسابرسی (Auditability): باید امکان بررسی و تأیید تراکنش‌ها وجود داشته باشد.
• امنیت (Security): نیاز به امنیت بسیار بالا برای محافظت از اطلاعات مالی.
• یکپارچگی داده‌ها (Data integrity): تراکنش‌های مالی باید دقیق و بدون تناقض باشند.
• مقیاس‌پذیری (Scalability): باید توانایی پشتیبانی از تعداد زیادی کاربر هم‌زمان را داشته باشند.

مزایده‌های آنلاین:

• قابلیت استفاده آسان (Usability): کاربران باید بتوانند به راحتی و سریع پیشنهاد قیمت ثبت کنند.
• ثبات در ثبت پیشنهادها (Consistency): پیشنهادها باید به صورت منظم و دقیق ثبت شوند تا مزایده درست عمل کند.
• قابلیت اطمینان (Reliability): سایت باید پایدار باشد؛ قطع شدن ارتباط در وسط مزایده تجربه بدی برای کاربر است.
• مقیاس‌پذیری (Scalability): باید توانایی پشتیبانی از تعداد زیادی پیشنهاددهنده را داشته باشد.

نکته:

هر دو حوزه (بانک و مزایده آنلاین) نیاز به مقیاس‌پذیری دارند. همچنین بیشتر ویژگی‌ها با پسوند “-ility” (مثل Security، Usability، Reliability) تموم می‌شن که نشون‌دهنده ویژگی‌های معماری هستن.

تعریف ویژگی‌های معماری

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

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

ویژگی‌های معماری، ملاحظات طراحی خارج از دامین هستن

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

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

مثلاً “کارایی بالا” یک ویژگی معماری مهمه، در حالی‌که معمولاً توی لیست نیازمندی‌ها نوشته نمی‌شه.

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

1. چیزهایی که به دامنه‌ی کاری سیستم مربوط می‌شن (مثلاً قوانین کسب‌وکار).
2. چیزهایی که به کیفیت و نحوه‌ی اجرای سیستم مربوط می‌شن (ویژگی‌های معماری).

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

ویژگی‌های معماری روی ساختار معماری تأثیر می‌ذارن

معمار وقتی ویژگی‌های معماری رو مشخص می‌کنه، دنبال اینه که ببینه آیا این ویژگی نیاز به پشتیبانی ویژه در ساختار سیستم داره یا نه.

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

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

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

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

محدود کردن ویژگی‌های معماری برای جلوگیری از پیچیدگی (Overengineering)

هر ویژگی اضافه یعنی پیچیدگی بیشتر. پس بهتره تعداد کمی ویژگی مهم و حیاتی رو انتخاب کنیم، نه اینکه همه‌چی رو پوشش بدیم.
ویژگی‌های معماری سه خاصیت مهم دارن:

قابل استانداردسازی نیستن

سازمان‌های مختلف ممکنه برای یه رفتار مشابه، اصطلاحات متفاوتی استفاده کنن. مثلاً «performance» و «responsiveness» ممکنه به یه چیز اشاره کنن.
نکته: داخل سازمان یه زبان مشترک برای این اصطلاحات درست کنید

روی همدیگه اثر دارن (Synergistic)

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

بیش از حد زیادن

ویژگی‌های معماری بسیار فراوانن، و هر روز ویژگی‌های جدیدی ظاهر می‌شن. مثلاً چند سال پیش چیزی به اسم «الاستیسیته در فضای ابری» وجود نداشت.

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

یادت باشه: به دام Resume-Driven Development (RDD) هم نیافتی!
یعنی فقط برای اینکه تکنولوژی‌های جدید رو تجربه کنیم یا رزومه قشنگ‌تر بشه، نریم همه‌چی رو به سیستم بچسبونیم.

در نظر گرفتن قابلیت‌های آشکار و پنهان

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

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

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

پس چیزهای مهمی مثل ساختار داخلی خوب چی می‌شن؟—اون‌هایی که هیچ‌کس به ذهنش نمی‌رسه ؟

بعضی از ویژگی‌های معماری پنهان خیلی ظریف‌تر هستن، ولی به همون اندازه مهمن. مثلاً معمارها باید حواسشون به ساختار داخلی اپلیکیشن باشه وقتی توسعه‌دهنده‌ها دارن اون رو می‌سازن، تا مطمئن بشن که کدنویسی بی‌دقت یا ضعف‌های دیگه باعث نشه عمر مفید نرم‌افزار پایین بیاد.
اما تقریباً هیچ لیست نیازمندی‌ای نمی‌گه: “لطفاً ساختار ماژولار سیستم رو خراب نکن!” یا “مطمئن شو که نرم‌افزار قابل نگهداری باشه!”