تا حالا شده که وقتی می‌خواین معماری نرم‌افزارتون رو برای افراد دیگه توضیح بدین، از نمودارها و دیاگرام‌ها استفاده کرده باشین؟ اگه جوابتون آره هست که احتمالاً همینطوره، از چه نمودارهایی استفاده کردین؟ UML؟ نمودارهای دیگه؟ شده که فرد غیرفنی تو تیمتون باشه و در فهم این نمودارا مشکل داشته باشه؟ اگه جوابتون آره هست، این نوشته برای شماست و داخل این نوشته در مورد روش C4 برای تجسم ساده‌تر از معماری نرم‌افزار صحبت می‌کنیم. اگه جوابتون نه هست هم خوندن مطلب ممکنه بهتون کمک کنه برای استفاده از نمودارهای قابل فهم‌تر برای ارائه در سندهای معماری نرم‌افزار.
اگر از یک معمار ساختمان یا حتی فردی که در صنعت ساختمان فعالیت داره، بخواین که براتون معماری ساختمانش رو براتون بکشه و توضیح بده، احتمالاً یه تصویر و نقشه از طبقات، قسمت‌های مختلف ساختمان و جزئیات اون ساختمان بهتون ارائه بده که احتمالاً با کمی نگاه کردن و دقت کردن بهش متوجه بشین چه معماری و نقشه‌ای در ذهن فرد مقابلی که اونو براتون کشیده هست.
حالا اگه از یک مهندس یا توسعه دهنده نرم‌افزار بخواین در مورد معماری نرم‌افزارش با استفاده از نمودارها توضیح بده، احتمالاً تعدادی باکس، خط، شکل‌های مختلف، رنگ‌های متفاوت و یه عالمه چیزای دیگه می‌بینید که هیچی ازش سردر نمیارید یا حداقل نمی‌دونید چرا این‌طوری ازشون استفاده شده. خب باید چیکار کرد؟ چطوری میشه از این نمودارای سخت‌فهمی که مشخص نیست دقیقاً چه قاعده و اصولی دارن به نمودارهای آسون‌فهم‌تر رسید؟! چی کار کنیم که بتونیم این خط، باکس، روابط پیچیده، انتزاع بیش از حد، واژه‌های خیلی عمومی و یه عالمه چیز دیگه که معمولاً تو این نمودارا استفاده میشه رو طوری برای بقیه ارائه و تجسم کنیم که قابل فهم تر باشه؟
خب! مهندسای نرم‌افزار و توسعه‌دهنده‌ها معمولاً تو چنین جاهایی از UML اسم می‌برن و ازش استفاده می‌کنن تا زبان مشترکی بین خودشون و بین آدمای غیرفنی تیم و در واقع کل افراد مرتبط با معماری اون نرم‌افزار داشته باشن. اینجاس که یه مشکلی معمولاً پیش میاد. آدمای غیرفنی معمولاً کمتر با نشانه‌گذاری‌های استفاده شده تو UML آشنا هستن. شاید بهتر باشه با راه حلی ساده‌تر و واضح‌تر با افراد تیم صحبت کرد که لازم نباشه قواعد UML یا نمودارای مشابه UML رو همیشه یادشون باشه. اینجاست که آقای Simon Brown مدل C4 رو برای ساده‌سازی و کاهش پیچیدگی این نمودارا ارائه می‌کنه و به افراد مرتبط با معماری نرم‌افزار کمک می‌کنه که به جای اینکه لازم بشه خیلی به قواعد کشیدن نمودارا فکر کنن، به خود نرم‌افزار بیشتر توجه کنن و صرفاً یه سری نکات رو برای کشیدن نمودارا رعایت کنن که در ادامه بهشون می‌پردازیم.
اگه با نقشه‌های مختلف کار کرده باشین، با زوم کردن به جزئیات بیشتری از یه مکان می‌رسید و با کم کردن زوم یه نمای کلی‌تر از مکان موردنظرتون رو می‌بینید. این دقیقاً راهی هست که مدل C4 برای تجسم بهتر از جزئیات لایه‌های مختلف نرم‌افزار ازش استفاده می‌کنه. تو این مدل به ارتباط بین تیم‌های مختلف مرتبط با نرم‌افزار توجه شده به طوری که هر فرد مرتبط با نرم‌افزار تا سطحی از جزئیات که بهش احتیاج داره از معماری نرم‌افزار و کد خبر داشته باشه و اگه به جزئیات و پیچیدگی‌های بیشتری احتیاج نداره، اصلاً این جزئیات رو بهش کاری نداشته باشه و در عین حال، سیستم رو به خوبی بفهمه.
مدل C4 همون‌طور که از اسمش پیداست از چهار سطح که با حرف C در انگلیسی شروع میشن، تشکیل شده که در مورد هر کدوم در ادامه توضیح می‌دیم.
در سطح اول از مدل C4 که در واقع نمودار زمینه سیستم (system context diagram) هست، یک شمای کلی از سیستم نرم‌افزاری در وسط داریم که کاربرها و سیستم‌های دیگه‌ای که با سیستم نرم‌افزاری مورد نظر ارتباط دارن در اطرافش قرار داره. تو این سطح، جزئیات نرم‌افزار نباید آورده بشه. به عنوان مثال نباید به تکنولوژی‌ها و جزئیات سطح پایین پرداخته بشه. چیزی که باید تو این سطح از مدل C4 بهش توجه بشه بیشتر خود سیستم اصلی و سیستم‌های مرتبط باهاش و کاربرهای سیستم‌مون هست. در واقع این سطح از نمودار، راه خیلی مناسبی برای ارتباط با افراد فنی و غیرفنی مرتبط با پروژه هست.
به عنوان مثال اگه یه سیستم بانک اینترنتی رو درنظر بگیریم، تو این سطح صرفاً خود سیستم رو به همراه یه توضیح از کارکرد سیستم در وسط داخل یک باکس میاریم و سیستم‌ها و کاربرایی که قراره باهاشون سیستم کار کنه رو در اطرافش میاریم که در این جا مشتری بانک اینترنتی به عنوان کاربر سیستم و سیستم‌های ایمیل و سیستم اطلاعات مرکزی بانک رو در اطرافِ باکس اصلی که در وسط قرار داره آوردیم. روابط بین کاربر و سیستم‌های مرتبط با سیستم اصلی رو هم روی فلش می‌نویسیم که چطوری هست.
برای اینکه بدونیم تو سطح دوم از مدل C4 باید چیا بیاد باید یکم زوم کنیم! اگه بخوایم جزئیات بیشتری از یه نقشه بدونیم چیکار می‌کنیم؟ زوم می‌کنیم دیگه! پس بیایم روی سیستم بانک اینترنتی خودمون یه مقدار زوم کنیم. وقتی که کمی زوم می‌کنیم می‌بینیم که این سیستم بانکی ممکنه شامل تعدادی ظرف باشه که هر ظرف در واقع یک واحد قابل اجرا یا استقراره که میتونه کد رو اجرا کنه یا داده تو اون ظرف ذخیره بشه. مثلاً به تصویر ۴ نگاه کنین. تو این تصویر، تعدادی باکس وجود داره. اپ موبایل، وب اپلیکیشن یا واحد API، ظرف‌هایی هستن که توشون کد میتونه اجرا بشه و Database بخشیه که داده داخلش میتونه ذخیره بشه. پس هر کدوم از این‌ها در واقع میتونن یه ظرف باشن.
در واقع نمودار ظرف‌ها یا همون container ها (که البته منظور در این جا چیزایی مثل docker نیست لزوماً!) یک نمودار سطح بالا از معماری نرم‌افزار و اینکه وظایف و کارهای مختلف سیستم، در کدوم بخش‌ها و چطوری تقسیم شدن هست. هم‌چنین تو این سطح از مدل C4، تکنولوژی‌های اصلی و اینکه این ظرف‌ها چطوری با هم ارتباط برقرار می‌کنن هم میاد. سطح ظرف‌ها از مدل C4، برای توسعه‌دهنده‌های نرم‌افزار و افراد دیگه‌ای مثل واحدهای عملیاتی و پشتیبانی میتونه مفید باشه.
حالا میخوایم ببینیم داخل هر ظرف، چه اجزایی وجود داره. اگه روی هر کدوم از ظرف‌هایی که تو سطح قبلی داشتیم زوم کنیم، بلاک‌ها و اجزای اصلی اون ظرف رو می‌بینیم. این اجزا در واقع، نماینده بخش‌های مختلف کد ما هستن که هر بخش رو می‌تونیم مثلاً به یه بخش یا بخش‌هایی از کد، مپ کنیم. در هر جزء، وظیفه اون جزء و جزئیات تکنولوژی و پیاده‌سازی جزء مورد نظر رو میاریم. این بخش بیشتر به درد افراد فنی پروژه مثل معمار نرم‌افزار و به خصوص توسعه‌دهنده‌ها میخوره.
اگه به تصویر ۵ دقت کنید، ظرف API از سطح قبلی رو روش زوم کردیم و اجزای مختلف اون که در واقع نماینده‌ای برای اجزای مختلف کد هستن مثل جزء ایمیل، جزء ریست کردن رمزعبور و اجزای دیگه قابل مشاهده هستن و وظیفه هر جزء مشخص شده و نحوه ارتباط این اجزا و هم‌چنین ارتباط این اجزا با ظرف‌های دیگه هم قابل دیدن هست.
داریم کم کم فول زوم می‌کنیم! اگه روی هر component زوم کنیم در واقع نحوه پیاده‌سازی اون جزء رو باید مشاهده کنیم. در سطح چهارم از مدل C4 پیاده‌سازی هر component رو می‌تونیم داشته باشیم و اینجاست که می‌تونیم مثلاً از UML ها یا دیاگرام ارتباط بین موجودیت‌ها یا چیزای مشابه استفاده کنیم.
معمولاً درستش اینه که این مقدار و این سطح از جزئیات در معماری نرم‌افزار نیاز نیست و معمولاً توصیه نمیشه تا این حد از جزئیات رو در نمودارهامون بیاریم و بهتره حتی اگه نیاز داشتیم که تا این سطح از نمودار رو داشته باشیم، از ابزارهای خود IDE ها برای این کار استفاده کنیم که مثلاً میتونن UML رو برامون جنریت کنن. البته باید دقت کنیم که حتی در همین نمودار، بخشی از ویژگی‌ها و متدها رو میاریم که مهم باشه و برای ارتباط با سایر اعضای تیم نرم‌افزار مفید باشه. بازم تکرار کنیم که این بخش از جزئیات توصیه نمیشه تو نمودارای معماری نرم‌افزار بیاد ولی اگه یه component خیلی پیچیده شد، خب شاید خوب باشه که سطح چهارم از مدل C4 هم آورده بشه. تصویر ۶ به عنوان مثال، کلاس‌های جزء mainframe رو نشون میدن.
در مورد نشانه‌گذاری در نمودارهای مختلفی که در معماری نرم‌افزار استفاده میشه، پیچیدگی‌های زیاد و مختلفی وجود داره که باعث میشه افراد غیرفنی یا افرادی که لازم نیست درگیر پیچیدگی باشن نیز مجبور بشن این نشانه‌گذاری‌ها رو یاد بگیرن. در مدل C4 هیچ نشانه‌گذاری‌ای از پیش تعریف نشده است. البته نشانه‌گذاری پیشنهادی وجود داره. مثلاً در مدل C4 نشانه‌گذاری پیشنهادی به سبک تصویر ۷ پیشنهاد میشه.
در واقع در استفاده از مدل C4، بیشتر به کارایی و معنای اجزا و توانایی این مدل برای سادگی تجسم معماری نرم‌افزار و ارتباط راحت‌تر بین اعضای فنی و غیرفنی برای توضیح آسان‌تر معماری توجه میشه. به اینکه مستند کردن معماری نرم‌افزار راحت‌تر و بدون توجه به پیچیدگی‌های غیرمفید باشه. در مدل C4 پافشاری خاصی روی نشانه‌گذاری وجود نداره.
ابزار Structurizr یک مجموعه ابزار برای ساختن و مستندکردن نمودارها و معماری نرم‌افزار به روش C4 هست که توسط سازنده خود مدل C4 یعنی آقای Simon Brown ساخته شده. این ابزار متن بازه و می‌تونید ازش استفاده کنید.
برای ارتباط بین افراد مختلف تیم‌های نرم‌افزاری لزوماً نیازی به افزودن پیچیدگی برای مستندسازی معماری و دانستن معلوماتی مثل نشانه‌گذاری‌های مختلف یا دانش فنی نیست. باید بیشتر به معنا و تجسم و ارتباط آسان‌تر و سریع‌تر و تمیزتر توجه کرد و نباید برای همه افراد فنی یا غیرفنی یک سطح از جزئیات را ارائه داد بلکه هر کدام به قسمتی از جزئیات نیاز دارن. حتی شاید لازم باشه شما که این نوشته رو خوندین هم یه بازنگری‌ای در مستندسازی معماری نرم‌افزار خودتون داشته باشین!
این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.
