به عنوان یک Software Architect (معمار نرمافزار) یا Senior Developer (توسعهدهنده ارشد)، احتمالاً بارها با این صحنه روبرو شدهاید:
جلسهای برای بررسی معماری سیستم برگزار میشود، وایتبرد پر از مربعها و دایرهها و خطوط درهمبرهم میشود. یکی از مربعها نشاندهنده Database (پایگاه داده) است و دیگری نشاندهنده کل Frontend (رابط کاربری سمت کاربر). هیچ استانداردی وجود ندارد و مخاطبِ غیرفنی کاملاً گیج شده، در حالی که تیم فنی هم نمیداند دقیقاً چه تکنولوژیهایی در حال استفاده است.
مشکل اصلی در مستندسازی معماری، فقدان یک "زبان مشترک بصری" و عدم توانایی در مدیریت Abstraction Levels (سطوح انتزاع) است. اینجاست که C4 Model وارد میدان میشود.
مدل C4 چیست؟
C4 Model که توسط Simon Brown معرفی شد، روشی برای مدلسازی معماری نرمافزار است که بر اساس یک استعاره ساده اما قدرتمند بنا شده است: Google Maps.
وقتی شما در گوگل مپ Zoom out میکنید، قارهها و کشورها را میبینید. کمی Zoom in میکنید، شهرها و جادههای اصلی نمایان میشوند. بیشتر زوم میکنید، محلهها و خیابانها را میبینید و در نهایت میتوانید جزییات یک ساختمان خاص را مشاهده کنید.
تصاویر این مقاله از سایت c4model گرفته شده است.
مدل C4 نیز دقیقاً همین کار را برای Software Architecture (معمار نرمافزار) انجام میدهد. این مدل سیستم را در چهار سطح مختلف از انتزاع و جزئیات توصیف میکند:
- Context (بستر سیستم)
- Containers (واحدهای اجرایی)
- Components (اجزا)
- Code (کد)
در ادامه به بررسی دقیق و فنی هر یک از این سطوح میپردازیم.
سطح ۱: System Context Diagram (نمودار بستر سیستم)
این بالاترین سطح است. در اینجا، ما اصلاً کاری به تکنولوژیها، پروتکلها یا کدها نداریم. هدف این نمودار نمایش "تصویر بزرگ" (Big Picture) است.
مخاطب این سطح: همه افراد!
از Stakeholders (ذینفعان تجاری)، مدیران پروژه و تحلیلگران کسبوکار گرفته تا تیمهای فنی و DevOps.
چه چیزی نمایش داده میشود؟
- Software System (سیستم نرمافزاری) که در حال طراحی یا مستندسازی آن هستید (در مرکز تصویر).
- Users (کاربران) یا Personas (نقشهای کاربری) که با سیستم تعامل دارند.
- External Systems (سیستمهای خارجی) که نرمافزار شما به آنها وابسته است (مانند سیستم پرداخت، سرویس ایمیل، یا Legacy Systems (سیستمهای قدیمی به ارث رسیده)).
نکته کلیدی: در این سطح مشخص میشود که سیستم شما در کجای اکوسیستم فناوری سازمان قرار میگیرد و مرزهای آن (System Boundaries) کجاست.
سطح ۲: Container Diagram (نمودار کانتینرها)
اینجا جایی است که یک مرحله "زوماین" میکنیم. اما قبل از ادامه، باید یک ابهام بزرگ را رفع کنیم.
هشدار فنی: در ادبیات C4، کلمه Container لزوماً به معنی Docker Container (کانتینر داکر) نیست!
در مدل C4، یک Container به معنای یک واحد اجرایی و قابل دیپلوی (Deployable Unit) است که دادهها را پردازش یا نگهداری میکند. یک کانتینر میتواند موارد زیر باشد:
- یک Single-Page Application (برنامه تکصفحهای وب) نوشته شده با React.
- یک Server-side Web Application (برنامه وب سمت سرور) مثلاً با .NET یا Java.
- یک Microservice (میکروسرویس) خاص.
- یک Database Schema.
- یک اپلیکیشن موبایل.
مخاطب این سطح:
تیم فنی، معماران نرمافزار، توسعهدهندگان و تیم Operations/Support.
چه چیزی نمایش داده میشود؟
در این نمودار، ما "جعبه سیاه" سیستم را باز میکنیم تا ببینیم از چه Container هایی تشکیل شده است. در این سطح باید تصمیمات تکنولوژی (Technology Choices) مشخص شوند. برای هر کانتینر باید بنویسیم که از چه تکنولوژی استفاده میکند (مثلاً: Golang, PostgreSQL, React Native) و نحوه ارتباط بین آنها (Inter-process Communication) چگونه است (مثلاً: HTTPS/JSON, gRPC, AMQP).
سطح ۳: Component Diagram (نمودار اجزا)
حالا وارد یکی از Containerها میشویم. فرض کنید میخواهیم داخل API Application را ببینیم. در این سطح، ما اجزای سازنده آن کانتینر را مدل میکنیم.
مخاطب این سطح:
توسعهدهندگان نرمافزار (Developers) و معماران فنی.
چه چیزی نمایش داده میشود؟
یک Component در اینجا به معنی گروهی از کدهای مرتبط است که پشت یک رابط مشخص (Interface) قرار گرفتهاند. اگر از زبانهای شیگرا استفاده میکنید، یک کامپوننت مجموعهای از کلاسهاست. مثلاً در یک سیستم فروشگاهی، داخل کانتینرِ Backend، ممکن است کامپوننتهای زیر را داشته باشیم:
- Sign-in Controller (کنترلکننده ورود)
- Audit Logger (ثبات وقایع)
- Payment Service (سرویس پرداخت)
- Inventory Repository (مخزن دادههای انبار)
در این سطح، جزییات پیادهسازی هنوز مخفی است، اما ساختار منطقی (Logical Structure) برنامه کاملاً شفاف میشود.
سطح ۴: Code Diagram (نمودار کد)
این عمیقترین سطح زوم است. اینجا ما وارد جزییات پیادهسازی میشویم. معمولاً از نمودارهای استاندارد UML Class Diagrams (نمودار کلاسهای UML) یا Entity Relationship Diagrams (نمودار موجودیت-رابطه) برای دیتابیس استفاده میشود.
مخاطب این سطح:
فقط توسعهدهندگان (Developers).
نکته مهم درباره سطح ۴:
در پروژههای مدرن، به ندرت توصیه میشود که این سطح را به صورت دستی مستند کنید.
چرا؟ چون کد دائماً در حال تغییر است و این نمودارها سریعاً منسوخ (Outdated) میشوند. پیشنهاد حرفهای این است که این سطح را یا کلاً نادیده بگیرید (چون خودِ کد بهترین مستند است) و یا توسط ابزارهای IDE و Auto-generation Tools (ابزارهای تولید خودکار) به صورت آنی تولید کنید.
Notation در C4
برخلاف UML که قوانین سفت و سختی برای شکل فلشها و نوع خطوط دارد، C4 در مورد نمادگذاری بسیار انعطافپذیر است. اما یک قانون طلایی وجود دارد:
هر شکل باید دارای برچسب (Label) واضح باشد.
ننویسید "User"، بنویسید:
- نام: مشتری بانک
- نوع: Person
- توضیح: شخصی که حساب بانکی دارد و از اپلیکیشن استفاده میکند.
یک خط ساده بین دو جعبه نکشید .
روی خط بنویسید:
- Makes API calls to [JSON/HTTPS]
چرا باید از C4 استفاده کنیم؟
۱. مدیریت پیچیدگی (Complexity Management): به جای اینکه همه چیز را در یک نمودار شلوغ جا دهید، پیچیدگی را به لایههای مختلف میشکنید.
۲. مقیاسپذیری (Scalability): این مدل هم برای یک استارتاپ کوچک با یک Monolith (معماری یکپارچه) مناسب است و هم برای سیستمهای پیچیده بانکی با صدها Microservice.
۳. استانداردسازی (Standardization): تیم شما یاد میگیرد که وقتی درباره "کانتینر" صحبت میکنیم، منظورمان چیست و هر مخاطب کدام نمودار را باید ببیند.
نتیجهگیری
مستندسازی به روش C4 Model فاصله بین مستندات گنگ و غیرفنی و دیاگرامهای پیچیده و غیرقابل فهم UML را پر میکند. با تفکیک سطوح به Context, Containers, Components و Code، شما به هر ذینفع دقیقاً همان اطلاعاتی را میدهید که نیاز دارد، نه کمتر و نه بیشتر.
اگر به دنبال ارتقای سطح حرفهایگری در تیم توسعه خود هستید، پیادهسازی C4 یکی از بهترین قدمهاست.