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

مزایای اصلی سند معماری نرم‌افزار:
• مستندسازی تصمیمات معماری و دلایل آن‌ها.
• تسهیل انتقال دانش به اعضای جدید تیم.
• کاهش ریسک وابستگی به افراد خاص.
• پایه ای برای ارزیابی و بازنگری معماری.
• کمک به برقراری زبان مشترک بین تیم‌های مختلف.


ساختار کلی SAD:

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

1. فضای مسئله (Problem Space):
در این بخش تمرکز بر تحلیل نیازها و اهداف سیستم است. مهم‌ترین زیربخش‌های این بخش عبارت است از:

• مقدمه:
شامل: توصیف کلی سیستم در حال طراحی، اهداف معماری، محدوده سیستم(Scope)، واژه‌نامه و اختصارات، مخاطبان این سیستم.

• نمای موارد کاربرد (Use Case View):
در این بخش، سناریوها و موارد کاربرد کلیدی سیستم تشریح می‌شوند. هدف آن است که تصویر دقیقی از نحوه استفاده از سیستم توسط کاربران یا سیسم‌های دیگر ارائه شود.

• ویژگی های کیفی (Quality Attributes):
ویژگی هایی مانند: دسترسی‌پذیری، کارایی، مقیاس‌پذیری، امنیت، قابلیت نگهداری و... . که برای هرکدام، معیارهای قابل اندازه‌گیری(مانند درصد دسترسی‌پذیری، زمان پاسخ و...) و معیار ارزیابی مطلوب مشخص می‌شود.


2. فضای راه‌حل (Solution Space):
در این بخش، معماری پیشنهادی برای سیستم از زوایای مختلف توصیف می‌شود. برای این منظور معمولا از مدل 1+4 استفاده می‌شود که شامل نماهای زیر است:

• نمای منطقی (Logical View): نمای کلی از مولفه‌های اصلی سیستم مانند: لایه‌ها، ماژول‌ها، سرویس‌ها و روابط بین آن‌ها. توضیحات این نما، مستقل از فناوری و اجرا توصیف می‌شود.

• نمای استقرار (Deployment View): توصیف محیط فیزیکی و اجرایی سیستم مانند سرورها، کانتینرها، داکرها، پایگاه‌های داده، فایروال‌ها و غیره. هدف این نما بررسی استقرار سیستم در محیط عملیاتی است.

• نمای پردازه (Process View): نمایشی از پردازه‌های اجرایی(برنامه‌های مستقل یا سرویس‌هایی که اجرا می‌شوند)، روابط و تعاملات بین آن‌ها و ویژگی‌های اجرایی مانند هم‌زمانی، مانیتورینگ و وضعیت اجرا. باید دقت داشت که این نما به معنای Business proccessها نمی‌باشد، بلکه System proccessها می‌باشد.

• نمای پیاده‌سازی (Development View): ساختار پروژه از دید برنامه‌نویسی، شامل پکیج‌ها، ماژول‌ها، لایه‌های کد، تصمیمات توسعه و سیاست‌های نسخه‌بندی.
• نمای سناریوها: توصیف معماری با استفاده از چند سناریوی مهم از تعامل سیستم، برای درک بهتر رفتار دینامیک اجزای سیستم.

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

• نمای تست: رویکردها، استراتژی‌ها و ابزارهای تست، همراه با ساختار تست پروژه و ارتباط آن با معماری.

• نمای لاگ و نظارت: ساختار لاگ‌ها، داده‌های ثبت شده، ابزارهای مدیریت و تحلیل رخداد.

• نمای پایش: ابزارها و رویکردهای استفاده از ابزارهای پایش(Monitoring) سیستم.

• نمای داده: معماری داده، ساختار پایگاه داده، فرآیندهای پشتیبان‌گیری، امنیت داده‌ها و ابزارهای گزارش‌گیری.

• الگوها و تکنیک‌ها: معرفی تاکتیک‌های پاسخ به ویژگی‌های کیفی(مانند کارایی). مرور این تکنیک‌ها در این بخش.

• فناوری‌ها و ابزارها: جدولی از ابزارها و فناوری‌های مورد استفاده، همراه با نسخه‌ها، جایگاه استفاده و محل استفاده.

• مهمترین تصمیمات معماری: ثبت تصمیمات مهم و کلیدی که تاثیر بالایی در معماری دارند.

• ریسک‌ها و بدهی‌های فنی: جدولی از مخاطرات فنی شناخته شده با توضیحات، اولویت، احتمال رخداد و تاثیر رخداد.

• نمای گزارش گیری: بیان ابزارها و ساختارهای مناسب برای ارائه انواع گزارش مانند مدیریتی، تحلیلی و... .

• بهبودهای پیشنهادی در آینده: جدول تغییرات پیشنهادی به همراه اولویت، اهمیت، دلیل، تاثیرات تغییر و وضعیت فعلی.

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


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

• نمودار زمینه (Context Diagram): نمایش کلی سیستم در تعامل با بازیگران، تمرکز بر محدوده سیستم و تعاملات کلان. که این بخش باید برای تمام ذینفعان قابل فهم باشد.

• نمودار کانتینر (Container Diagram): نمایش اجزای اصلی(اپلیکیشن‌ها، سرویس‌ها، پایگاه داده؛ در اینجا، کانتینر به معنای داکر نیست بلکه منظور، یک ساختار اجرایی در زمان اجرا می‌باشد)، تمرکز بر فناوری‌ها و مسئولیت‌ها. مناسب برای درک تصمیمات معماری کلان.

• نمودار مولفه (Component Diagram): نمایش اجزای داخلی یک کانتینر و نحوه تعامل میان آن‌ها. مناسب برای طراحی معماری داخلی سرویس‌ها.

• نمودار کد (Code Diagram): نمایش ساختار کد مانند نمودارهای کلاس. معمولا توسط IDE تولید شده و اختیاری است.

ویژگی‌ها و نکات مدل C4: مستقل از زبان مدلسازی مانند UML، اصطلاحات قابل تطبیق(ماژول، مولفه، تابع)، امکان افزودن سطوح بیشتر با حفظ وضوح، قابل استفاده برای معماری یکپارچه و مایکروسرویس، پشتیبانی از ابزارهای ساده تا پیشرفته برای طراحی نمودارها، و درنهایت فرآیند طراحی را تحمیل نمی‌کند.

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