سند معماری نرم افزار
سند معماری نرم افزار، یه نقشه راه سطح بالا برای ساخت یک سیستم نرم افزاریه. این سند توصیف می کنه که سیستم قراره چجوری ساخته بشه، از چه اجزایی تشکیل بشه، این اجزا چطور با هم کار کنن، چه تصمیمات مهمی برای طراحی سیستم گرفته شه و برای همه ی افراد فنی و حتی غیرفنی که به نحوی در پروژه درگیرن کاربرد داره.
سند معماری یه فایل اضافه برای بایگانی پروژه نیست. یه ابزار کاربردیه برای اینکه تیم های مختلف بتونن با هم هماهنگ باشن، مخصوصا وقتی تیم بزرگ تر می شه، وجود یه سند مرکزی که همه بتونن بهش مراجعه کنن خیلی کمک کننده ست. از طرف دیگه، سند معماری باعث می شه صحبت بین افراد راحت تر باشه. چون همه یه تصویر مشترک از سیستم دارن. فایده ی مهم دیگه هم اینه که از وابستگی شدید به افراد خاص جلوگیری می کنه. بعضی وقتا فقط یه نفر هست که کل ساختار سیستم تو ذهنشه و اگه اون فرد نباشه، حتی یه تغییر ساده هم ممکنه دردسرساز بشه. ولی وقتی همه ی تصمیمات کلان و ارتباطات اصلی مستند شده باشه، حتی اگه افراد جا به جا بشن یا تیم تغییر کنه، سیستم قابل فهم و قابل نگهداری باقی می مونه.
داشتن سند معماری با توسعه چابک هیچ تضادی نداره. مستندسازی باید به اندازه و هدف دار باشه. یه سند معماری خوب، به جای اینکه سرعت تیم رو کم کنه، باعث می شه تصمیم گیری ها سریع تر و دقیق تر باشن.
وقتی قراره یه سند معماری نوشته بشه، برای اینکه هم نویسنده بدونه چی باید بنویسه و هم خواننده راحت بتونه مطالب رو پیدا کنه و بفهمه، یه قالب مشخص لازمه. این قالب شامل دو بخش اصلی هست: فضای مسئله و فضای راه حل.
فضای مسئله
این بخش به ما می گه اصل نیاز چیه؟ قراره چه کاری انجام بشه؟ سیستم چه قابلیت هایی باید داشته باشه؟ چه محدودیت هایی وجود داره؟
این اطلاعات پایه برای طراحی معماری خیلی مهمه. چون نمی شه بدون اینکه بدونیم قراره چه مشکلی حل بشه، براش راه حل طراحی کنیم. فضای مسئله از چند بخش تشکیل شده:
- مقدمه: یه معرفی کلی از سیستم، دامنه پروژه، واژه نامه، اهداف کلی معماری و محدودیت هایی که توی طراحی باید در نظر گرفته بشن.
- نمای موارد کاربرد (Use Case View) : اینجا مشخص می شه که کاربران سیستم کی هستن و چه کارهایی قراره انجام بدن. به هرکدوم از این کارها می گیم Use Case. این قسمت کمک می کنه مطمئن بشیم طراحی ای که انجام می دیم واقعا نیازها رو پوشش می ده یا نه.
- ویژگی های کیفی (Quality Attributes) : مهم تر از اینکه سیستم چی کار می کنه، اینه که چطور کار می کنه. این ویژگی ها باید شفاف بیان بشن و براشون معیار سنجش تعریف بشه.
فضای راه حل
بعد از اینکه صورت مسئله رو دقیق نوشتیم، وقتشه بریم سراغ طراحی راه حل. یعنی توصیف کنیم که سیستم قراره از چه اجزایی تشکیل بشه، این اجزا چطور با هم تعامل دارن، کجا اجرا می شن، چطور توسعه پیدا می کنن و چطور مانیتور می شن. این بخش اصلی ترین قسمت سند معماریه و شامل یه سری نما (View) مختلفه که هر کدوم از یه زاویه خاص به سیستم نگاه می کنن و وقتی کنار هم قرار می گیرن، یه تصویر کامل از سیستم به دست میاد.
- نمای منطقی (Logical View) : توی این قسمت، سیستم به اجزای اصلی تقسیم می شه. تمرکز اینجا روی ساختار مفهومی سیستمه، نه پیاده سازی. یعنی کاری نداریم ماژول ها با چه زبانی نوشته شدن یا کجا اجرا می شن؛ فقط می خوایم بدونیم چه اجزایی وجود دارن و چطور با هم تعامل دارن.
- نمای استقرار (Deployment View) : مشخص می کنه اجزای سیستم قراره کجا اجرا بشن. این نما برای تیم زیرساخت و DevOps مفیده. توی این نما، دو سطح استقرار منطقی و استقرار فیزیکی تعریف می شه.
- نمای پردازه (Process View): این قسمت درباره ی اجزای اجرایی سیستمه. یعنی پردازه هایی که واقعا در زمان اجرا وجود دارن؛ مثل سرویس ها و ماژول های مستقل و اینکه این پردازه ها چطور با هم ارتباط دارن.
- نمای پیاده سازی (Development View) : اینجا ساختار پروژه ها، زیر پروژه ها، بسته ها (Packages) و وابستگی ها و لایه های مختلف کدنویسی مثل UI ،Service و Data Access مشخص می شن.
- نمای تست (Test View) : این بخش توضیح می ده که سیستم چطور تست می شه، چه تست هایی در نظر گرفته شدن و با چه ابزارهایی اجرا می شن. همچنین مشخص می کنه کدوم بخش ها بیشتر نیاز به تست دارن و چطور در طراحی معماری لحاظ شدن.
- نمای لاگ (Log View) : این نما نشون می ده چه اطلاعاتی در سیستم لاگ می شن، فرمت لاگ ها چیه و سیستم لاگینگ چطور پیاده سازی شده.
- نمای پایش (Monitoring View) : مشخص می کنه که سلامت سیستم چطور مانیتور می شه، چه شاخص هایی پایش می شن و در صورت بروز مشکل چه نوع هشدارهایی فعال می شن.
- نمای داده (Data View) : این قسمت ساختار کلی داده ها، نوع پایگاه داده ها، سیاست های نگهداری و بازیابی (Backup & Restore) و روش های حفظ امنیت و یکپارچگی داده ها رو مشخص می کنه.
مدل C4
یه روش مستند سازی معماریه که طوری طراحی شده که بشه راحت ازش استفاده کرد، مخصوصا در تیم های چابک که فرصت مستندسازی سنگین ندارن. مدل C4 از چهار سطح تشکیل شده که هر کدوم سیستم رو از یه زاویه خاص بررسی می کنه:
- سطح Context : یه تصویر کلی از جایگاه سیستم در دنیای بیرون رو نشون می ده. مشخص می شه چه کسانی با سیستم کار می کنن و چه سیستم های دیگهای باهاش در ارتباط هستن. مثلا تو سامانه فروش، کاربران، درگاه پرداخت و سیستم پیامکی می تونن تو این نمودار باشن. این نمودار برای افراد غیر فنی مفیده چون دربارهی روابط سطح بالا صحبت می کنه.
- سطح Container : سیستم به بخش های مستقل و قابل اجرا تقسیم می شه. مثل اپلیکیشن وب، اپلیکیشن موبایل، API و پایگاه داده. به هر جز قابل استقرار container گفته می شه و این همون کانتینر Docker نیست. این سطح نشون می ده هر بخش چه وظیفهای داره و با کدوم بخش های دیگه در ارتباطه.
- سطح Component : وقتی وارد یک container می شیم، با مؤلفه های مختلفی رو به رو می شیم. مثلا اگه کانتینر ما یه API باشه، مؤلفه هایی مثل احراز هویت، مدیریت سفارش و گزارش گیری داخل اون قرار دارن. تو این سطح مشخص می شه که هر مؤلفه چه کاری می کنه و با کدوم مؤلفه های دیگه در ارتباطه. بیشتر به درد توسعه دهنده ها می خوره چون نشون می ده مسئولیت هر بخش از کد کجاست.
- سطح Code : آخرین سطح که معمولا دستی ترسیم نمی شه، چون ابزارهایی مثل IDE یا UML خودشون می تونن ساختار کلاس ها، فایل ها و توابع رو تولید کنن. تو این سطح وارد جزئیات کد، وابستگی ها و ساختارهای داخلی می شیم.
مدل C4 علاوه بر اینکه می گه چی بکشیم، می گه چطور بکشیم تا قابل فهم هم باشه. برای مثال:
- وضوح و شفافیت خیلی مهمه. نمودارها باید خوانا باشن. استفاده از فونت مناسب و فاصله گذاری درست، کمک می کنه که مخاطب راحت تر ارتباط بین اجزا رو درک کنه.
- هر عنصر باید اسم، نوع و توضیح داشته باشه. مثلا اگه یه container داریم به اسم Payment API، باید مشخص باشه که نوعش چیه (Application)، وظیفه ش چیه (پردازش پرداخت ها) و با چه پروتکل هایی ارتباط می گیره.
- ارتباطات بین اجزا باید برچسب داشته باشن. یعنی وقتی دو مؤلفه با هم ارتباط دارن، باید مشخص بشه این ارتباط از چه نوعیه و چه اطلاعاتی بین شون رد و بدل می شه.
- استفاده از رنگ ها، آیکون ها یا حتی لوگوها، می تونه فهم نمودار رو بهتر کنه، البته به شرطی که زیاد و شلوغ نشه.
