گزارشی از اهمیت و ساختار سند معماری نرم‌افزار (SAD) و نگاهی کوتاه به مدل C4

مقدمه
این گزارش در مورد سند معماری و ویژگی ها و موارد مطرح شده در آن بعد از اینکه به صحبت‌های استاد، دکتر علی اکبری، در مورد سند معماری نرم‌افزار ([1]SAD) گوش دادم و ویدیوی آقای سایمون براون در مورد مدل C4 را دیدم، و همچنین اسلایدها و سایت c4model.com را بررسی کردم، نوشته شده است.

همچنین این محتوا در پست لینکدین هم در لینک زیر قابل مشاهده است:

لینک پست لینکدین :

https://www.linkedin.com/posts/hasan-roknabadi-663854303_%DA%AF%D8%B2%D8%A7%D8%B1%D8%B4%DB%8C-%D8%A7%D8%B2-%D8%A7%D9%87%D9%85%DB%8C%D8%AA-%D9%88-%D8%B3%D8%A7%D8%AE%D8%AA%D8%A7%D8%B1-%D8%B3%D9%86%D8%AF-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-activity-7331695411457429505-V58l?utm_source=share&utm_medium=member_desktop&rcm=ACoAAE2Lw6sBPbQg4zjjJqpOgk15lYbqrZpCkxU

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

• همه با هم یک چیز را بفهمند: همانطور که در اسلاید ۶ میبینیم، SAD کمک می‌کند تا معمار، تیم فنی (طراح‌ها و برنامه‌نویس‌ها)، مدیرها، کارفرما و بقیه افرادی که در پروژه نقش دارند (چه فنی باشند چه نباشند)، یک درک مشترک از معماری داشته باشند.
• تصمیم‌های مهم فراموش نشوند: در معماری کلی تصمیم فنی مهم گرفته می‌شود. SAD این تصمیم‌ها و اینکه چرا گرفته شده‌اند (مثلاً چرا از فلان تکنولوژی استفاده کردیم) را ثبت می‌کند. این موضوع مخصوصاً در پروژه‌های بزرگ یا وقتی اعضای تیم عوض می‌شوند، خیلی به درد می‌خورد.
• دانش معماری گم نشود: خیلی وقت‌ها دانش معماری فقط توی ذهن معمار یا چند نفر از بچه‌های تیم است. SAD کمک می‌کند این دانش که شاید "پراکنده و ناقص" باشد، به صورت "واضح و کامل" نوشته شود .
• ریسک کمتر و وابستگی کمتر به یک نفر: یکی از بهترین فایده‌هایش که در اسلاید ۸ با عنوان "Bus Factor" گفته شده، این است که دیگر پروژه خیلی به یک نفر خاص وابسته نمی‌شود. اگر فقط یک نفر معماری را بلد باشد و از تیم برود، پروژه به مشکل می‌خورد.
• راهنمای تیم و آموزش نیروهای جدید: SAD به تیم فنی کمک می‌کند ساختار کلی سیستم را بفهمند و کارشان را بهتر انجام دهند. برای آموزش نیروهای جدید هم خیلی خوب است .
• راحت‌تر می‌شود معماری را بررسی کرد و مشورت گرفت: وقتی یک سند منظم داشته باشیم، راحت‌تر می‌توانیم معماری را ارزیابی کنیم یا از متخصص‌های دیگر مشورت بگیریم.
• با روش‌های چابک هم جور درمی‌آید: شاید فکر کنیم مستندسازی با چابکی مخالف است، اما اسلایدهای ۱۰ و ۱۲ خوب توضیح می‌دهند که منظور از چابکی، این نیست که اصلاً مستند نداشته باشیم، بلکه باید "فقط به اندازه لازم و مفید" مستند درست کنیم (Just Enough). یک SAD خوب حتی می‌تواند به چابک بودن پروژه کمک کند، البته به شرطی که خودش هم سریع و راحت تهیه و آپدیت شود.

سند معماری نرم‌افزار (SAD) باید شامل چه چیزهایی باشد؟
بر اساس اسلایدها ، یک SAD خوب معمولاً دو قسمت اصلی دارد: "فضای مسئله" و "فضای راه‌حل" .

• الف) فضای مسئله[2]: هدف این بخش این است که دقیقاً بگوییم نرم‌افزار قرار است چه مشکلی را حل کند.
  1. مقدمه : یک توضیح کوتاه در مورد نرم‌افزار، اینکه پروژه دقیقاً شامل چه چیزهایی می‌شود و چه چیزهایی نمی‌شود.
  2.نمای موارد کاربرد[3] : مشخص کردن اینکه چه کسانی (Actors) از سیستم استفاده می‌کنند و کارهای اصلی که سیستم باید انجام دهد چه هستند. این بخش به ما می‌گوید سیستم چه کارهایی باید بتواند انجام دهد.
  3. ویژگی‌های کیفی[4]: مشخص کردن ویژگی‌های مهم غیرکارکردی سیستم مثل سرعت ، همیشه در دسترس بودن ، امنیت ، راحت بودن تغییرات بعدی و غیره. مهم است که این ویژگی‌ها را بشود اندازه گرفت و برای هر کدام مثال‌هایی (سناریو) تعریف کنیم . (این بخش به طور کامل در کلاس نیز تدریس شده است و بیشتر از این به آن نمیپردازیم)
• ب) فضای راه‌حل[5]: این بخش توضیح می‌دهد که معماری چطور مشکل را حل می‌کند و ویژگی‌های کیفی را برآورده می‌کند. چند نمای مختلف در این بخش داریم:
  1. نمای منطقی - [6]: توضیح بخش‌های اصلی معماری (Building Blocks)، زیرسیستم‌ها، سرویس‌ها و اینکه چطور با هم کار می‌کنند، البته در یک سطح کلی و مفهومی.
  2. نمای استقرار [7] - : اینکه نرم‌افزار چطور روی سخت‌افزار و سرورها نصب و اجرا می‌شود .
  3. نمای پردازه[8] - : توضیح برنامه‌های در حال اجرا، و اینکه چطور با هم ارتباط برقرار می‌کنند و چه اتفاق‌هایی در زمان اجرای نرم‌افزار می‌افتد (مثلاً مدیریت همزمانی کارها).
  4. نمای توسعه و پیاده‌سازی[9] - : ساختار پروژه از نگاه برنامه‌نویس‌ها، یعنی ماژول‌ها، پکیج‌ها و لایه‌های مختلف کد.

5. بخش‌ها و نماهای مهم دیگر (اسلایدهای ۷۳ به بعد):

• نمای پویا[10]: نشان می‌دهد که بخش‌های مختلف سیستم چطور با هم کار می‌کنند تا یک کار خاص (مثلاً یک مورد کاربرد مهم) انجام شود. معمولاً با نمودارهای توالی نشان داده می‌شود.
• نمای تست، لاگ و پایش (Test, Log, Monitoring Views): روش‌ها و ابزارهایی که برای تست نرم‌افزار، ثبت اتفاقات (لاگ‌ها) و بررسی وضعیت سیستم استفاده می‌شود.
• نمای داده[11]: تصمیم‌هایی که در مورد پایگاه داده، مدیریت داده‌ها و الگوهای مربوط به آن گرفته شده و الگوها و تکنیک‌هایی که استفاده شده است.
• تصمیم‌های مهم معماری[12]: (این بخش در فیلم تدریسی استاد وجود ندارد و در اسلاید های جدید است.) این بخش که در اسلایدهای ۲۷-۳۰ به آن اشاره شده، برای اینکه بدانیم "چرا" یک تصمیم خاص گرفته شده، خیلی مهم است برای دانستن ریسک‌ها و بدهی‌های فنی (چیزهایی که می‌دانیم مشکل دارند ولی فعلاً حل نشده‌اند) و مسائل مربوط به امنیت و گزارش‌گیری.

مدل C4: یک روش کاربردی برای نشان دادن معماری

آقای سایمون براون در ویدیوی خود و اسلایدهای ۱۶ تا ۲۵ استاد، مدل C4 که یک روش ساده و مرحله به مرحله را معرفی کردند که برای نشان دادن معماری نرم‌افزار در چهار سطح مختلف است. این مدل کمک می‌کند تا معماری را راحت‌تر بفهمیم و به بقیه هم نشان دهیم و با همان اصل "فقط به اندازه لازم" هم جور در می‌آید.

1. سطح ۱: نمودار زمینه[13] : کلی‌ترین سطح که سیستم نرم‌افزاری ما را مثل یک جعبه سیاه نشان می‌دهد و می‌گوید با چه کسانی و چه سیستم‌های دیگری در ارتباط است. این نمودار را همه، حتی کسانی که فنی نیستند، می‌فهمند.
2. سطح ۲: نمودار کانتینر[14] : اگر روی آن جعبه سیاه زوم کنیم، بخش‌های اصلی قابل اجرا یا قابل نصب (کانتینرها) را می‌بینیم. کانتینر می‌تواند یک برنامه وب، یک اپ موبایل، یک پایگاه داده و غیره باشد. اینکه این کانتینرها چطور با هم حرف می‌زنند و از چه تکنولوژی‌هایی استفاده می‌کنند هم در این سطح معلوم می‌شود.
3. سطح ۳: نمودار کامپوننت[15]: هر کانتینر را می‌توانیم به بخش‌های کوچکتری به اسم کامپوننت تقسیم کنیم. کامپوننت‌ها مجموعه‌ای از کارهای مرتبط هستند و معمولاً در کد به صورت ماژول یا پکیج دیده می‌شوندمثلاً یک کنترلر در معماری[16] .
4. سطح ۴: نمودار کد : جزئی‌ترین سطح که ساختار کد مثل کلاس‌ها و ارتباط بین آن‌ها را نشان می‌دهد. همانطور که گفته شد، معمولاً این سطح را دستی در SAD نمی‌نویسیم و ابزارهایی مثل IDEها می‌توانند آن را تولید کنند.

نکته‌های مهم در مورد C4:

ابزارهایی مثل Structurizr وجود دارند(که سایمون برایون آن را دولوپ کرده است!!) که کمک می‌کنند این نمودارها را با نوشتن متن (DSL) درست کنیم. اینطوری نگهداری و آپدیت کردنشان کنار کد خیلی راحت‌تر می‌شود.(سایمون برایون در اخر ویدیو اشاره میکند که اصلا از ابزارهایی مثل ویزیو استفاده نکنید زیرا برای معماری نرم افزار طراحی نشده است.)

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

حرف آخر و چند توصیه از طرف من:
با دیدن این ویدیوها و خواندن اسلایدها، به این نتیجه رسیدم که:

• سند معماری یک چیز ثابت نیست و باید در طول پروژه آپدیت شود .
• نباید خودمان را درگیر جزئیات خیلی ریز و بی‌اهمیت کنیم . باید روی تصمیم‌های بزرگ و تاثیرگذار تمرکز کنیم.
• بهتر است از یک قالب مشخص برای SAD استفاده کنیم (حتی اگر لازم شد تغییرش بدهیم) تا همه چیز یکدست و قابل فهم باشد .
• مدل C4 یک راه خیلی خوب برای کشیدن نمودارهایی است که همه بفهمند و در سطوح مختلف جزئیات را نشان می‌دهد.
• نوشتن اینکه "چرا" یک تصمیم معماری گرفته شده (ADRs) به اندازه خود معماری مهم است.
• مسئول نوشتن و نگهداری SAD باید یک نفر باتجربه و فنی در تیم باشد .

• [1] Software Architecture Document
• [2] Problem Space
• [3] Use Case View
• [4] Quality Attributes
• [5] Solution Space
• [6] Logical View
• [7] Deployment/Physical View
• [8] Process View
• [9] Development/Implementation View
• [10] Dynamic View / Use Case Realization
• [11] Data View
• [12] Architecture Decision Records - ADRs
• [13] System Context Diagram
• [14] Container Diagram
• [15] Component Diagram
• [16] MVC