مدل مستندسازی C4 برای اولین بار در سال 2006 توسط يکي از معماران نرم‌افزار به نام آقای سایمون براون ابداع شد. او ایده‌هایی برای بصری سازی معماری نرم‌افزار داشت، که در این مقاله به بررسی اجمالی آن‌ها خواهیم پرداخت.
در چرخه توسعه‌ی یک نرم‌افزار، بیشترین تمرکز بر روی کد پروژه است و این کاملاً منطقی است. چرا که خروجی آن همان محصولی است که تحویل مشتری داده می‌شود. اما آیا اين منطقی است که توضیح یک سیستم را از کد آن شروع کنیم؟
پرواضح است که شروع توضیح معماری سیستم از روی کد ایده چندان مناسبي نيست. از اين رو به‌جای کد، معماران شروع به توضیح معماری توسط علایم و اشکالی مانند نمودارهاي UML می‌کنند تا بتوانند معماری سيستم خود را به دیگران (و خودشان) بهتر بفهمانند. اما نمودارهای UMLمشکلاتی هم دارند، که از آن جمله مي توان به عدم آشنايي بسیاری از اعضای تیم با علایم UML نام برد. به همين دليل، معماران نرم‌افزار تلاش کردند تا طرح‌های ابتکاری خودشان بر روی کاغذ ارائه دهند. اما آیا این نمودارها برای تمامي افرادي که در پروژه نرم‌افزاری مشارکت دارند (اعم از برنامه‌نویس، طراح، مدیرمحصول و ...) قابل فهم هستند؟
اگرچه ممکن است خروجی این دیاگرام‌ها زیبا و شکیل باشد، اما همچنان برای درک سیستم کمک چندانی به ما نمی‌کند.
بنابراین مي توان اينگونه برداشت کرد که نمودارهایی که امروزه برای بیان معماری نرم‌افزار گفته می‌شوند، چندان کاربردی نیستند و چه بسا باعث سردرگمی ديگران نیز بشوند.
از نظر آقای براون ضرورتي ندارد که تمامي افرادی که درگیر یک پروژه معماری هستند به یک اندازه از معماری سیستم اطلاع داشته باشند. برای مثال برنامه‌نویس با توجه به اینکه درگیر پیاده‌سازی است، نیاز دارد تا بیشترین اطلاعات را از معماری سیستم داشته باشد. درحالی‌که لزومی ندارد تا مالک محصول بسیاری از جزئیات معماری نرم‌افزار را بداند. پس بهتر است معماری نرم‌افزار در قالب سطوح مختلفی بیان شود.
از نظر آقای براون، زمینه فعالیت (context) ما یک سامانه نرم‌افزاری است که این سامانه از تعدادی کانتینر تشکیل شده است. در اینجا کانتینر به معنای فرآیند ایزوله شده در سطح سیستم‌عامل - همان مفهومی که داکر بیان می‌کند- نیست. بلکه به معنای یک اپلیکیشن مستقل است که تحت این سامانه فعالیت می‌کند(مانند یک وب اپلیکیشن یا موبایل اپلیکیشن). درون هر کانتینر نیز تعدادی کامپوننت درون فعالیت هستند که تجمیع آن‌ها برابر با عملکرد کانتینر است. مثل میکروسرویس‌هایی که درون یک وب اپلیکیشن اجرا می‌شوند. اما خود این کامپوننت ها نیز از قطعه‌های کد تشکیل شده اند. این قطعات می‌توانند توابع یا کلاس‌ها باشند.
براون سیستم نرم‌افزاری را به ۴ سطح از انتزاع تقسیم می‌کند که هر سطح دانه‌بندی متفاوتی با سطح دیگر در بیان معماری نرم‌افزار دارد. او این ایده در توصیف معماری سیستم را به نام مدل C4، یعنی Context، Container، Component و Code تقسیم کرد.
تصویر فوق، نمایانگر سطوح انتزاع در مدل C4 است که خلاصه آن به شرح زیر است:
زمینه (Context): یک نمودار با سطح انتزاع بالا است که برای ما اسکوپ پروژه را مشخص می‌کند و نیازمندی‌ها و بازیگران اصلی سیستم را به ما نشان می‌دهد و سعی می‌کند به این سؤالات پاسخ دهد :
کانتینر (Container): در لایه‌ي container یک قسمت از سیستم که در سطح context نمایش داده شده است، تشریح می‌شود. یک کانتینر دیاگرام تاحدی مشخص می‌کند که از چه تکنولوژی‌هایی در پروژه استفاده کرده‌ایم، مسئولیت‌ها چگونه توزیع شده‌است و کانتینرها چگونه با یکدیگر ارتباط برقرار می‌کنند. نمودار کانتینر سعی دارد که به این سؤالات پاسخ دهد:
کامپوننت (Component): هر کانتینر از چندین کامپوننت تشکیل شده است. در سطح مولفه، جزئیات کامپوننت را موشکافانه بررسی می‌کنیم. این بررسی شامل شناسایی اجزای اصلی یک کامپوننت و روابط بین آن‌ها می‌شود. سطح کامپوننت سعی در پاسخ‌گویی به این سؤالات دارد:
کد (Code): هر کامپوننت توسط واحد‌های کد پیاده‌سازی می‌شود که پایین‌ترین سطح انتزاع در مدل C4 است. کدها معمولاً در قالب نمودارهای UML بیان می‌شوند و سطح پیچیدگی این نمودارها به درجه سختی پروژه یا تجربه تیم بستگی دارد.
براي درک بهتر موارد فوق را به مثال زير توجه کنيد:
فرض کنيد مي خواهيم معماری یک سیستم بانکی انتزاعی را با C4 نمایش دهیم.
همانطور که گفتیم، سطح context بالاترین سطح انتزاع را بین بازیگران سیستم مشخص می‌کند. تصویر بالا، ارتباط مشتریان با سیستم بانکی که جهت انجام امور مختلف مانند نمايش صورت حساب و پرداخت استفاده می‌شود را نشان مي دهد. برای این‌کار نرم‌افزار بانکداری اینترنتی از سامانه mainframe بانک که از قبل پیاده‌سازی شده است، استفاده می‌کند. برای ارسال ایمیل نیز، از یک سامانه ارسال ایمیل استفاده شده که قبلاً پیاده‌سازی شده است. این را از رنگ‌های اشکال در جدول متوجه می‌شویم. رنگ خاکستری به معنای سامانه‌های از قبل پیاده‌سازی شده است و رنگ آبی به معنای سامانه‌ای است که قرار است پیاده‌سازی شود.
در سطح کانتینر، قسمتی از سیستم بانکداری را باز می‌کنیم. سامانه بانکداری از کانتینر‌های متفاوتی تشکیل شده است. کانتینر در اینجا به معنای برنامه‌های موبایل، کنسول، وب یا … است.
برای مثال، سامانه بانکداری ما از موبایل اپ، اپلیکیشن تک صفحه‌ای (SPA) ، پایگاه داده و API اپلیکیشن تشکیل شده است. هر کدام از این موارد یک کانتینر هستند و روابط بین آن‌ها نیز در نمودار مشخص شده است. برای مثال کانتینر موبایل اپ اینترفیسی برای کار با سیستم بانکداری اینترنتی برای مشتریان فراهم می‌کند و برای پرداخت یا ارسال ایمیل، از کانتینر API استفاده می‌کند. برای ادامه در سطوح پایینتر، کانتینر API را مورد بررسی قرارمی‌دهیم.
همانطور که مشاهده می‌شود، کانتیر API Application از چندین کامپوننت شامل، کامپوننت‌های ایمیل، امنیتی، ارتباط با سامانه Mainframe و … تشکیل شده است که ارتباط این کامپوننت‌ها در سطح کامپوننت نشان داده می‌شود.
جزئیات سطح کد شیوه پیاده‌سازی کامپوننت را مشخص می‌کند. سطح کد معمولاً با نمودارهای UML نمایش داده می‌شود. به توصیه طراح C4، این سطح از جزئیات تنها براي مهم ترین یا پیچیده ترین اجزا توصیه می‌شود. تصویر فوق، شیوه پیاده‌سازی کامپوننت ارتباط با Mainframe بانک در کانتینر API Application را نشان می‌دهد.
مدل C4 نمادی رسمی برای نشانه‌گذاری ندارد. C4 سعی در ساده کردن نماد‌ها دارد تا بتوان در هر جا معماری را به سادگی رسم کرد. البته تیم‌ها می‌توانند با استفاده از نشانه‌های UML یا نشانه‌های ابداعی خودشان در سطوح مختلف، مستندسازی معماری نرم‌افزار را انجام دهند.
در C4 تنها الزام به نوشتن نام نمودارها است اما بسیار توصیه می‌شود که برای هر نمودار توضیحی ذکر شود. ضمناً اگر برای توصیف نمودار از اشکال قراردادی استفاده می‌کنیم، لازم است حتما توضیحی برای آن‌ها نوشته شود.
تقریبا تمامی ابزارهای عام منظوره جهت رسم نمودارهای مهندسی نرم‌افزار. منتها توصیه می‌شود که از ابزارهای عام‌منظوره‌ای مانند draw.io، gliffy یا visio استفاده نشود. به جای آن ابزارهای خاص منظوره‌ای که معرفی می‌کنیم استفاده کنید.
این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهید بهشتی است.
https://www.youtube.com/watch?v=x2-rSnhpw0g
