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

پیدا کردن ویژگی‌های مهم

«می‌بینم کلی ویژگی معماری داریم… ولی از کجا بفهمم کدومشون برای پروژه من واقعا مهمه؟»

ویژگی‌های معماری همین‌جوری از هوا پیدا نمی‌شن!
سه جا هست که باید سراغشون برید تا بفهمید کدوم ویژگی‌ها رو لازم دارید:

۱. دامنه مسئله (Problem Domain)

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

۲. شناخت محیط (Environmental Awareness)

یه بخش از نیازمندی‌ها، از شناخت درست محیط کاری میاد.
مثلاً این که دارید توی یه استارتاپ تند و تیز کار می‌کنید یا توی یه شرکت بزرگ و سنگین که هر تصمیم اشتباه، کلی ضرر می‌زنه.

💡 یادآوری: بعضی ویژگی‌ها خودشون رو مستقیم نشون نمی‌دن و «ضمنی» هستن. خیلی وقت‌ها این ویژگی‌های پنهان، از همین دو مورد اول درمیاد.

۳. دانش کلی از دامنه (Holistic Domain Knowledge)

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

استخراج ویژگی‌های معماری از دامنه مسئله (Problem domain)

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

مثال: اگه توی نیازمندی‌ها گفته شده «هزاران کاربر»، شما به‌عنوان معمار باید دقیق‌تر بررسی کنید:

• چند نفر واقعاً انتظار می‌رود از سیستم استفاده کنن؟ (Scalability)
• چند نفر همزمان آنلاین می‌شن؟ (Concurrency)
• کاربران با چه سرعت و الگویی وارد سیستم می‌شن؟ (Elasticity)

استخراج ویژگی‌های معماری از آگاهی محیطی (Environmental awareness)

شما درباره محیط کاری خودتون اطلاعات زیادی دارید (گاهی هم بیش از حد!) و همین باعث می‌شه تحلیل ویژگی‌های معماری طبیعی شکل بگیره.
مثلاً یک معمار که توی یه استارتاپ سریع کار می‌کنه، حتی اگه توی نیازمندی‌ها گفته نشده باشه، اولویت رو به Agility می‌ده.

💡 یادآوری: یعنی باید تو جلسات اولویت‌بندی کسب‌وکار خوب گوش بدید!

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

💡 یادآوری: معمارها نمی‌تونن تصمیم بگیرن بدون اینکه زمینه و context رو در نظر بگیرن.

استخراج ویژگی‌های معماری از دانش جامع دامنه (Holistic domain knowledge)

برخی معمارها دقیقاً توی یک دامنه خاص می‌مونن چون دانش عمیق اون دامنه براشون مزیت داره.

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

مثال: فرض کنید یه شرکت می‌خواد یه کمپین تبلیغاتی تو دانشگاه برگزار کنه و دانشجوها رو ثبت‌نام کنه.
برای ساده‌سازی، فرض کنیم ۱۰۰۰ دانشجو هستن و ۱۰ ساعت وقت دارن برای ثبت‌نام.
آیا سیستم رو طوری طراحی کنیم که فرض کنیم دانشجوها به طور مساوی تو این ۱۰ ساعت تقسیم می‌شن؟
واقعیت اینه که این روش جواب نمی‌ده: بعضی دانشجوها خیلی زرنگ و سریع هستن، بعضی‌ها همیشه تعلل می‌کنن.
پس طراحی سیستم باید یه «جریان ناگهانی» از دانشجوها رو تو اولین ساعت جواب بده، روز معمولاً آرام بمونه، و قبل از بسته شدن ثبت‌نام دوباره یه موج ناگهانی برای افراد عقب‌افتاده مدیریت کنه.

💡 یادآوری: هیچ‌وقت توانایی بعضی دانشجوها برای تعلل رو دست کم نگیرید!

معمارها باید از همه منابع اطلاعاتی استفاده کنن تا همه trade-offهای تصمیمات معماری رو درک کنن.

مراقب باش! راه‌حل‌ها در برابر نیازمندی‌ها

بیشتر وقت‌ها مشتری‌ها با راه‌حل میان، نه نیازمندی واقعی.

مثال تاریخی: تو دهه ۱۹۷۰، نیروی هوایی آمریکا خواست یه جت جنگنده بسازه که سرعتش به ۲.۵ ماخ برسه.
طراح‌ها تلاش کردن ولی فناوری اون زمان جواب نمی‌داد. وقتی از نیروی هوایی پرسیدن چرا ۲.۵ ماخ لازمه، جواب دادن: «خب، این جت‌ها گرونن و می‌خوایم بتونه در صورت لزوم از درگیری فرار کنه.»
با این اطلاعات، طراح‌ها F-16 رو طراحی کردن: حداکثر سرعت ۲.۱ ماخ، ولی چابک‌ترین و سریع‌ترین شتاب‌گیرنده جت تا اون زمان.

پس وقتی کاربران راه‌حل میارن، کار معمار اینه که مثل یه بچه کنجکاو بپرسه: «چرا؟!؟» تا نیاز واقعی که پشت راه‌حل پنهانه، مشخص بشه.

اولویت‌ها به شرایط پروژه بستگی دارند

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

ترجمه نیازهای پروژه:

هیچ‌کدوم از کارشناسان حوزه‌ (domain exprets) نمی‌دونن «مقیاس‌پذیری (Scalability)» و «انعطاف‌پذیری (Elasticity)» چیه.
پس چطور قراره خودشون بفهمن و درخواست این ویژگی‌ها رو بدن؟

تبریک! یه کار جدید هم داری

حق داری که نسبت به درک همکارانت از مفاهیم معماری شک داشته باشی.
این یعنی یه مسئولیت جدید هم به عنوان معمار داری: ترجمه کردن!

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

گم شدن در ترجمه

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

چند مثال برای روشن شدن این موضوع هم در ادامه آورده شده.

وقتی تحلیلگران کسب‌وکار و کارشناسان حوزه می‌گن:
۱. «سیستم همواره در حال تغییره تا با نیازهای جدید بازار هماهنگ بشه.»
معمارها ترجمه می‌کنن:

• چابکی (Agility)
• ماژولار بودن (Modularity) ← ماژولار بودن خوب باعث می‌شه تغییرات سریع بدون ایجاد اثرات جانبی رخ بده.
• قابلیت گسترش (Extensibility)

۲. «به دلیل قوانین و مقررات جدید، باید پردازش انتهای روز رو به موقع انجام بدیم.»
معمارها ترجمه می‌کنن:

• کارایی (Performance) ← باید عملکرد خوبی داشته باشیم و در عین حال در صورت خطا سریع بازیابی کنیم.
• قابلیت بازیابی (Recoverability)
• مقیاس‌پذیری (Scalability)

۳. «برنامه ما اینه که طی سه سال آینده در ادغام‌ها و تملک‌ها به شدت فعال باشیم.»
معمارها ترجمه می‌کنن:

• قابلیت به‌روزرسانی رزومه (Résumé-ability) ← «توانایی به‌روزرسانی رزومه». خیلی‌ها ترجیح می‌دن تو محیطی کار نکنن که دائماً در حال ادغام و تغییره.
• قابلیت یکپارچگی (Integratability)
• قابلیت همکاری بین سیستم‌ها (Interoperability)

۴. «ما برای این پروژه زمان محدودی داریم و بودجه و محدوده مشخصی داریم.»
معمارها ترجمه می‌کنن:

• امکان‌سنجی (Feasibility) ← ارزیابی اینکه چیزی امکان‌پذیره یا نه، یه ویژگی معماری کم‌استفاده شده است.
• سادگی (Simplicity) ← بیشتر به ویژگی شخصیتی خود معمار مربوطه.
• مقرون‌به‌صرفه بودن (Affordability) ← معمارها اغلب دید منحصر به فردی نسبت به امکان‌پذیری در چارچوب زمان و بودجه دارن.

هرچی ویژگی‌های معماری بیشتر باشه به معنی بهتر بودن نیست!

«تحلیل‌گرهای کسب‌وکار من نه تنها اصطلاحات فنی مربوط به ویژگی‌های معماری رو نمی‌فهمن، بلکه همیشه کلی درخواست هم دارن!»

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

محدود کردن ویژگی‌های معماری

وقتی ذی‌نفع‌های کسب‌وکار می‌خوان همه‌ی ویژگی‌های معماری ممکن رو داشته باشن، چطور می‌تونی جلوی اشتیاقشون رو بگیری؟

عدد جادویی ۷

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

نکات کلیدی فصل

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

ویژگی‌های معماری، توانایی‌های یه سیستم رو توصیف می‌کنن.

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

دسته‌بندی‌های مختلفی برای ویژگی‌های معماری وجود داره. هیچ‌کس نمی‌تونه لیست کاملی ارائه بده، چون اکوسیستم توسعه نرم‌افزار دائماً در حال تغییره.

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

معماران باید مراقب باشن که ویژگی‌های معماری زیادی رو مشخص نکنن، چون این ویژگی‌ها روی همدیگه اثر میزارن — تغییر دادن یه کدوم، نیازمند تغییر بخش‌های دیگه‌ی سیستمه.

برخی از ویژگی‌های معماری ضمنی هستن: توی نیازمندی‌ها به صورت صریح ذکر نشدن، ولی بخشی از ملاحظات طراحی یه معمار محسوب می‌شن.

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

خیلی از ویژگی‌های معماری مقطعی هستن: با بخش‌های دیگه‌ی سازمان (و تصمیماتش) تعامل دارن.

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

برخی از ویژگی‌های معماری از دانش دامنه و/یا دانش محیطی میان، نه از نیازمندی‌های یه اپلیکیشن خاص.»

برخی از ویژگی‌های معماری ترکیبی هستن: از ترکیب چندتا ویژگی معماری دیگه به وجود میان.

معماران باید یاد بگیرن که «زبان کسب‌وکار» رو به ویژگی‌های معماری ترجمه کنن.

معماران باید تعداد ویژگی‌های معماری‌ای که در نظر می‌گیرن رو به یه عدد کوچیک محدود کنن، مثلاً هفت تا.