هر سیستمی که در این جهان ایجاد می‌شود دارای معماری است، هر چند کسی معماری آن را ننوشته باشد. معماری درواقع یک دید کلی نسبت به یک سیستم است تا به کمک آن بتوان اجزای سازنده، ارتباط میان اجزا، تکنولوژی‌های مورد استفاده و هدف از ایجاد آن سیستم را فهمید.
از آنجایی که نرم‌افزار هم یک سیستم است بنابراین برای آن نیز می‌توان معماری تعریف کرد و مستند نمود. معماری سیستم‌های نرمافزاری در مقایسه با معماری سایر محصولات و سیستم‌ها کمی متفاوت و سخت‌تر است. زیرا نرم‌افزار یک موجود بسیار پیچیده و توسعه‌پذیر است و هر لحظه، با توجه به شرایط و قوانین محیطی، دستخوش تغییراتی شود. بنابراین یک ویژگی اساسی در معماری نرم‌افزار علاوه‌بر ساده و قابل فهم بودن، قابلیت توسعه‌پذیری آن است. . نکته‌ی دیگری که اهمیت دارد آن است که بتوان یک معماری را به خوبی مستند کرد و در اختیار ذینفعان آن سیستم نرمافزاری قرار داد. هدف از مستند کردن معماری آن است تا افراد تازه وارد مانند توسعه دهندگان یا مدیران جدید بتوانند در یک نگاه سیستم را بفهمند و به هدف آن پی ببرند.
برای مستند کردن معماری روش و مدل مشخصی ارائه داده نشده است و برخی تیم‌ها از نمودارهایی استفاده می‌کنند که فقط توسط خودشان قابل فهم است یا برخی دیگر از استانداردهای UML استفاده می‌کنند. روشی که قرار است برای مستند سازی انتخاب شود باید قابل فهم باشد، سیستم را از جنبه‌های مختلف توصیف کند و در عین حال سریع بتوان آن را توسعه داد. به عنوان مثال استفاده از نمودارهای UML ممکن است که ایده‌ی خوبی بنظر برسد و یک سیستم را به خوبی از جنبه‌های مختلف و به طور دقیق توصیف کند اما دارای پیچیدگی و جزئیات زیادی است و برای رسم و گسترش آن وقت بسیاری باید گذاشت که با توجه به سرعت پیشرفت و گسترش سیستم‌های نرمافزاری انتخاب مناسبی نیست. بین سال‌های ۲۰۰۶ تا ۲۰۱۱ روش و مدلی توسط آقای Simon Brown برای مستند سازی معماری نرم‌افزار به نام C4 مطرح شد. این مدل یک سیستم نرمافزاری را در ۴ سطح مورد بررسی قرار می‌دهد و روی جزئیات خیلی تمرکز نمی‌کند و سعی دارد تا به صورت مختصر و مفید اطلاعات آن سیستم را در اختیار ذینفعان قرار دهد. در بخش بعدی به توضیح بیشتر این مدل خواهیم پرداخت
کلمه C4 مخفف ۴ کلمه‌ی Component، Container، Context و Code است. هر کدام از این کلمات بیانگر یک سطح از معماری هستند و در هر سطح میزان بیان جزئیات متفاوت است و هر چه از Context به Code حرکت می‌کنیم به جزئيات معماری افزوده می‌شود.
در سطح Context تنها خود سیستم نرمافزاری که قصد توسعه آن را داریم یا در حال توسعه آن هستیم، نشان داده می‌شود. در این نمودار ارتباط میان سیستم با سایر سیستم‌ها و کاربران را به خوبی می‌توان نشان داد. به طور کلی می‌توان گفت محیطی را که سیستم قرار است با آن تعامل داشته باشد را به خوبی بیان میکند و درواقع به صورت کلی به سیستم نگاه میکند. به عنوان مثال تصویر ۱،یک نمونه از نمودار Context است. در این تصویر یک سیستم بانکداری اینترنت قرار دارد که همان سیستم نرمافزاری ما می‌باشد. کاربران این سیستم مشتریان بانک هستند که می‌توانند موجودی خود را مشاهده کنند و پرداخت‌های خود را انجام دهند. همچنین اطلاعات حساب‌ها را از سیستم بانکداری مرکزی می‌گیرد و با یک سرویس ایمیل نیز، برای ارسال پیام به کاربران، در ارتباط است. همانگونه که مشاهده می‌کنید این نمودار اطلاعات محیطی سیستم را به خوبی نمایش می‌دهد و کاربران این نمودار برای فهم آن نیاز به دانش خاصی ندارند و تنها مختص توسعه دهنده و معمار نرم‌افزار نمی‌باشد.
یک سیستم نرمافزاری از مجموعه‌ای از اجزا تشکیل شده است که به آن‌ها Container می‌گویند. Containerها همان برنامه‌ها و پایگاه‌های ذخیره اطلاعات هستند مانند: برنامه‌های موبایل، برنامه‌های تحت وب و APIها. در این نمودار نوع، تعداد و ارتباط میان Containerها نمایش داده می‌شود و تکنولوژی‌های استفاده شده نیز قابل نمایش است. به عنوان مثال می‌توان نشان داد که در یک برنامه‌ی تحت وب از چه فریم‌ورکی(Framework) استفاده شده است. از ویژگی‌های Containerها این است که هر کدام به صورت جداگانه قابلیت دیپلوی شدن دارند و وابسته به Container دیگری نیستند. مخاطبان این نمودار افراد فنی هستند چه آن‌هایی که در داخل تیم حضور دارند و چه بیرون تیم. تصویر ۲، درون سیستم بانکداری اینترنتی را نشان می‌دهد که از چه Containerهایی تشکیل شده است و چه ارتباط‌هایی میان آن‌ها برقرار است.
سومین سطح از مدل Component ،C4ها هستند که اجزای سازنده‌ی یک Container نیز می‌باشند. هر Component از مجموعه‌ای از کلاس‌ها تشکیل شده است مانند Controllerهایی که برای یک Container پیاده‌سازی می‌شوند. در نمودار Component مسئولیت‌ها و جزئیات پیاده‌سازی هر کدام نشان داده شده هست. در تصویر ۳، Componentهای API برنامه نشان داده شده است که در این نمودار وظیفه‌ی هر Component و ارتباط میان آن‌ها به خوبی نشان داده شده.
سطح چهارم و آخر که جزئی‌ترین سطح نیز می‌باشد، سطح Code است که کدهای سازنده‌ی یک Component را نشان می‌دهد. البته این سطح اختیاری است و آقای Brown در کنفرانس Agile on the beach در سال ۲۰۱۹ توصیه کردند که از این نمودار استفاده نشود، به دلیل جزئیات زیادی که دارد و از طرفی نمودارهای مربوط به Code را می‌توان از خود IDE استخراج کرد و نیازی به رسم نمودار دیگری نیست. در تصویر ۴ نمونه‌ای از این نمودار را مشاهده می‌کنید.
همچنین مخاطبان و استفاده کنندگان در دو سطح آخر، Component و Code، توسعه‌دهندگان و معماران نرم‌افزار هستند.
در مدل C4 علائم خاصی برای رسم نمودارها به صورت یک قرار داد و قانون گفته نشده ولی پیشنهاداتی داده شده است. اما تاکید شده است که استفاده‌ی درست از علائم و نوشتن توضیحات بسیار مهم است و در فهم نمودار بسیار کمک میکند. از مواردی که در رسم نمودار مهم است خط‌هایی است که برای نمایش ارتباط میان جعبه‌های(Box) نمودار کشیده می‌شود. خطوط باید به صورت یک طرفه باشند نه دو طرفه. در برخی مواقع که بین دو جعبه مجبور به رسم دو یا بیشتر خط هستیم می‌توان یک خط میان آن دو بکشیم و یک توضیح مناسب نیز روی خط اتصال کننده بنویسیم. این کار سبب کاهش شلوغی و پیچیدگی نمودار می‌شود. به عنوان مثال در تصویر ۱، ارتباط میان سیستم بانکداری اینترنت با بانکدار مرکزی را با دو خط می‌توان بیان کرد، یک خط برای درخواست اطلاعات از سمت سیستم بانکداری اینترنتی و یک خط دیگر برای پاسخ بانکداری مرکزی به بانکداری اینترنتی. اما همانگونه که مشاهده می‌کنید با یک خط و توضیح مناسب برروی آن ارتباط میان دو سیستم بیان شده است. بنابراین باید به توضیحاتی که درون جعبه‌ها و بین خطوط ارتباطی می‌نویسیم توجه کنیم. نکته‌ی دیگر در مورد لیستی از علائم مانند رنگ‌ها، شکل‌ها، خط‌ها و غیره است. علائم استفاده شده در نمودار باید معلوم باشند که هر کدام نشان دهنده‌ی چه چیزی هستند تا در فهم بهتر و سریع‌تر نمودار کمک کند و مخاطب گیج نشود. همچنین از آیکون‌ها نیز می‌توان به عنوان تکمیل کننده‌ی یک جزء از نمودار استفاده شود به عنوان مثال در تصویر ۲ می‌شد از آیکون‌های Angular و JS ،که در تصویر ۵ نشان داده شده‌اند، به عنوان تکنولوژی‌های استفاده شده در برنامه‌ی Single-Page استفاده کرد و دیگر نیازی به نوشتن توضیح نبود. در استفاده از آیکون‌ها نباید زیاده‌روی کرد و به جای جعبه‌ها یا توضیح در برخی مواقع از آیکون استفاده کرد زیرا این کار ممکن است برای تیم توسعه یا معماری سیستم قابل فهم باشد اما برای یک فرد فنی خارج از سازمان غیرقابل فهم باشد.
برای رسم نمودارهای C4 ابزارهایی هم معرفی شده‌اند مانند C4-PlantUML و Structurizr که مختص رسم نمودارهای معماری نرم‌افزار هستند. اما نکته‌ای که در انتخاب ابزار رسم این نمودارها مهم است آن است که نباید ابزارهایی را انتخاب کرد که با هدف‌های عمومی برای رسم نمودارها ایجاد شده‌اند مانند Visio. زیرا طبق گفته‌ی آقای Brown این گونه ابزارها به صورت تخصصی برای معماری نرم‌افزار طراحی نشده‌اند و فهمی هم از سیستم‌های نرمافزاری ندارند، بنابراین برای مستند کردن معماری ابزارهای خوبی نمی‌توانند باشند.
هر سیستم نرمافزاری که ساخته می‌شود یک معماری دارد بنابراین بهتر است که معماری آن را مستند کرد زیرا، نرم‌افزار یک محصولی است که مرتب در حال تغییر و گسترش است و افرادی که توسعه می‌دهند ممکن است تغییر کنند و افراد جدید به تیم توسعه اضافه شوند و با وجود مستند معماری به خوبی می‌توانند سیستم را بفهمند. برای مستند کردن آن مدلی به نام C4 معرفی شده است. این مدل معماری یک سیستم نرمافزاری را در چهار سطح Component، Container، Context و Code بررسی میکند. ابتدا در سطح Context با محیطی که نرم‌افزار درگیر آن است آشنا می‌شوید و با وارد شدن به درون سیستم با Containerهای سازنده‌ی آن مانند APIها و برنامه‌های تحت وب. برای دیدن محتویات درون هر Container نیز می‌توانید به نمودار Component مربوط به آن Container مراجعه کنید و در صورت لزوم، کدهای هر Component نیز به کمک نمودار Code قابل مشاهده است. بنابراین به کمک این مدل به خوبی می‌توان معماری یک سیستم را با جزئیات مختلف بیان کرد.
این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است
