de_DEen_USes_ESfa_IRfr_FRhi_IN

بزرگنمایی تا انتها: درک نمودارهای کد C4 – اینها چی هستند، چه زمانی ارزش افزوده ایجاد می‌کنند و مثال‌های عملی PlantUML

نمودار کد C4 چیست؟

نمودار کد این استسطح 4— عمیق‌ترین و جزئی‌ترین سطح در مدل C4 سیمون براون.

The Ultimate Guide to C4 Model Visualization with Visual Paradigm's AI Tools - ArchiMetric

نشان می‌دهد:

  • کلاس‌هارابطه‌هاانواع محدودرکوردهایا سایر ساختارهای سطح کد که یک مؤلفه خاص را پیاده‌سازی می‌کنندمؤلفه (از سطح 3).

  • رابطه‌ها بین آن کلاس‌ها (میراث، ترکیب، وابستگی، پیاده‌سازی رابطه‌ها و غیره).

  • عناصر طراحی کلیدیعناصر طراحی مانند الگوهایی که در داخل مؤلفه اعمال شده‌اند (مثلاً ذخیره‌سازها، خدمات، DTOها، موجودیت‌های دامنه، کارخانه‌ها).

در عمل، این سطح تقریباً همیشه یکنمودار کلاس UML (یا یک نسخه ساده‌شده) که بر روی یک (یا تعداد بسیار کم) مؤلفه متمرکز است.

توضیح مهم:

  • سطح 4 این است کهنه درباره کل پایگاه کد نیست.

  • ایننهمورد نیاز برای نمایش هر کلاس.

  • این نقشه برداری می‌کندتنها ساختار ضروریمورد نیاز برای درک اینکه یک مؤلفه پیچیده یا حیاتی چگونه واقعاً ساخته می‌شود.

  • توصیه رسمی C4:به طور ایده‌آل خودکار تولید شدهاز کد منبع (از طریق ابزارهایی مانند Doxygen، Javadoc + پلاگین‌های UML، yWorks، Structurizr، CodeSee و غیره) به جای نقاشی دستی.

زمان مناسب برای ایجاد یک نمودار کد

نمودارهای سطح 4 را به ندرت ایجاد کنید — فقط در این موارد:

  • مؤلفهبسیار پیچیدهحیاتییادشوار برای درکتنها از طریق کد منبع (مثلاً منطق حوزه‌ای پیچیده، استفاده شدید از الگوهای طراحی، جریان‌های رمزنگاری، ماشین‌های حالت، کد قدیمی پر از بدهی فنی).

  • شما در یکصنعت بسیار مورد تنظیم (مالی، بهداشت، فضایی، دفاعی) که در آن بازرسان یا تیم‌های انطباق، نیاز به نقشه‌برداری صریح از معماری → طراحی → پیاده‌سازی دارند.

  • در طولبازسازی اصلیکشتن یک مؤلفه قدیمییامعرفی یک الگوی معماری جدید (هگزاگونال، تمیز، برش عمودی، مجموعه‌های DDD) — نمایش قبل و بعد به انتقال تغییر کمک می‌کند.

  • ورود به سیستمتوسعه‌دهندگان ارشدیامعمارانکسانی که می‌خواهند ساختار داخلی پیچیده و غیرقابل‌مشاهده یک بخش خطرناک کد را به سرعت درک کنند.

  • شما قبلاً در تولید خودکارابزارها — بنابراین نگهداری سطح ۴ هزینه‌ای تقریباً ندارد.

  • تیم توافق کرده است که «مستندات زنده»در سطح کلاس برای این زیرسیستم خاص ارزشمند است.

در موارد زیر از ایجاد نمودارهای سطح ۴ خودداری کنید:

  • ساختار مؤلفه‌ها از طریق نام‌گذاری مناسب، اندازه کوچک یا کد تمیز واضح است (اکثر سرویس‌های میکرو مدرن در این دسته قرار می‌گیرند).

  • شما قبلاً دارید  تست‌های واحد/یکپارچه خوبرابطه‌های واضح، و توضیحات توضیحی.

  • اکثر تیم به راحتی می‌توانند در کد جابجا شوند.

  • هزینه نگهداری از مزیت بیشتر است (نمودارهای کلاس دست‌کشیده بسیار سریع منقضی می‌شوند).

سیمون براون و اکثر متخصصان تأکید می‌کنند: اکثر تیم‌ها هرگز به سطح ۴ نیاز ندارندسطح‌های ۱ و ۲۸۰ تا ۹۰ درصد نیازهای ارتباطی را پوشش می‌دهند؛ سطح ۳بیشتر بقیه موارد را مدیریت می‌کند. سطح ۴ استثناست، نه قاعده.

چرا از نمودارهای کد استفاده کنیم؟ (وقتی ارزش افزوده داشته باشند)

  • پل بین معماری ↔ پیاده‌سازی— نشان می‌دهد که مؤلفه‌های سطح بالا در کد به چه شکلی پیاده‌سازی شده‌اند.

  • وضوح بخش‌های پیچیده طراحی داخلی— کاربرد الگوها (استراتژی، کارخانه، دکوراتور، ذخیره‌سازی)، نقض لایه‌بندی، اتصال شدید یا مدل‌سازی هوشمندانه حوزه را آشکار می‌کند.

  • حمایت از بازبینی‌ها و انطباق — نشان می‌دهد که تصمیمات معماری تا کد اجرا شده ادامه می‌یابد.

  • کمک به بحث‌های بازسازی و انتقال — ساختارهای کلاس قبل و بعد پیشنهادات را قابل درک می‌کنند.

  • کاهش «دانش قبیله‌ای» — به استخدام‌های جدید سطح بالا کمک می‌کند تا بخش‌های پیچیده را سریع‌تر از خواندن تمام فایل‌های منبع درک کنند.

  • نسخه‌های خودکار به «مستندات زنده» تبدیل می‌شوند — اگر ابزارها در دسترس باشند، با تقریباً هیچ تلاشی دقت خود را حفظ می‌کنند.

چگونه یک نمودار کد عالی بسازیم (مراحل به‌صورت گام‌به‌گام + بهترین روش‌ها)

  1. یک مؤلفه را انتخاب کنید — معمولاً از نمودار سطح 3 که پیچیدگی داخلی آن باعث تقویت بزرگ‌نمایی می‌شود، انتخاب می‌شود.

  2. تصمیم بگیرید: دست‌کشیده یا تولیدشده؟

    • دست‌کشیده → فقط برای کارگاه‌ها، پیشنهادات یا مناطقی که برای ابزارهای خودکار بی‌نظم هستند.

    • تولیدشده → ترجیح داده می‌شود (می‌توان از PlantUML برای استایل‌دهی/بهبود خروجی استفاده کرد).

  3. بر روی ضروریات تمرکز کنید — نشان دهید:

    • کلاس‌ها/رابطه‌های کلیدی

    • رابطه‌های مهم (→ وابستگی، — ترکیب، <| پیاده‌سازی، ^ ارث‌گیری)

    • مجموعه‌ها، موجودیت‌ها، اشیاء مقداری (سبک DDD)

    • الگوها یا الگوهای معکوس مهمی که می‌خواهید برجسته کنید

  4. آن را کوچک نگه دارید — حداکثر 8 تا 15 کلاس. اگر بزرگ‌تر باشد → به نمودارهای متمرکز تقسیم شود (مثلاً «برش احراز هویت»، «موجودیت‌های پردازش سفارش»).

  5. بهترین روش‌ها

    • ترجیح دهیدتولید خودکار هرگونه که ممکن است (کمتر بودن قدیمی‌بودن).

    • ازPlantUML classDiagram سینتکس — تمیز و قابل نسخه‌داری.

    • افزودنیادداشت‌هابرای تصمیمات غیرمستقیم (مثلاً «از مدل دامنه بی‌قدرت استفاده می‌کند – بازسازی برنامه‌ریزی شده»).

    • از نمایش اجتناب کنیدهمه چیز— از نمایش متد‌های ساده گِت‌ر/سِتِر و کلاس‌های کمکی صرف نظر کنید.

    • در مخزن ذخیره شود → به عنوان کد رفتار کنید (فایل‌های .puml را نزدیک به مؤلفه ارسال کنید).

    • به ندرت استفاده کنید — یکی برای هر مؤلفه پیچیده، نه یکی برای هر میکروسرویس.

    • با هم ترکیب کنیدنمایش‌های پویا (دنباله/همکاری) اگر جریان اجرا مهم‌تر از ساختار استاتیک باشد.

مثال PlantUML – مؤلفه احراز هویت (گسترش سبک Big Bank plc)

اینجا یک مثال واقع‌بینانه سطح 4 آمده که به سمتمؤلفه امنیت / احراز هویتاز دیاگرام‌های قبلی برنامه کاربردی API گرفته شده است.

@startuml
title C4 سطح 4 – دیاگرام کد: احراز هویت درون برنامه کاربردی API

skinparam monochrome true
skinparam shadowing false
skinparam class {
  BackgroundColor White
  BorderColor Black
  ArrowColor Black
}

abstract class AuthenticationProvider {
  + authenticate(credentials): Authentication
}

class JwtAuthenticationProvider {
  - tokenProvider: JwtTokenProvider
  - userDetailsService: UserDetailsService
  + authenticate(credentials): Authentication
}

class JwtTokenProvider {
  - secretKey: String
  - validityInMilliseconds: long
  + generateToken(userDetails): String
  + validateToken(token): boolean
  + getUsernameFromToken(token): String
}

interface UserDetailsService {
  + loadUserByUsername(username): UserDetails
}

class DatabaseUserDetailsService {
  - userRepository: UserRepository
  + loadUserByUsername(username): UserDetails
}

class UserRepository {
  + findByUsername(username): Optional<User>
}

class User {
  - username: String
  - passwordHash: String
  - roles: Set<Role>
}

class JwtAuthenticationToken << (T,orchid) Authentication >> {
  - principal: UserDetails
  - credentials: Object
  - authorities: Collection<GrantedAuthority>
}

' Relationships
JwtAuthenticationProvider -up-> JwtTokenProvider : uses
JwtAuthenticationProvider -up-> UserDetailsService : uses
DatabaseUserDetailsService .up.|> UserDetailsService
DatabaseUserDetailsService --> UserRepository : uses
UserRepository --> User : returns

JwtAuthenticationToken .up.|> Authentication

note right of JwtAuthenticationProvider
  جریان اصلی احراز هویت برای جلسات بدون حالت مبتنی بر JWT
end note

note bottom of JwtTokenProvider
  امضای و تأیید JWTها با استفاده از HS512
end note

@enduml

این دیاگرام کوچک:

  • فقط بر جزئیات داخلی احراز هویت تمرکز دارد

  • کلاس‌های کلیدی، رابط‌ها و وابستگی‌ها را نشان می‌دهد

  • الگوها را برجسته می‌کند (ارائه‌دهنده، ذخیره‌سازی)

  • از یادداشت‌ها برای ارائه زمینه استفاده می‌کند

در هر رندرر PlantUML کپی کنید — برای حوزه خود سفارشی‌سازی کنید (مثلاً JWT را با OAuth2 جایگزین کنید، کلاس‌های MFA اضافه کنید و غیره).

یادآوری خلاصه: سطح 4 قدرتمند است امانادر. آن را به صورت عمدی استفاده کنید، تولید خودکار را ترجیح دهید و هرگز به کارهای بی‌مورد تبدیل نکنید. بیشترین ارزش C4 از سطوح 1 تا 3 حاصل می‌شود. مدل‌سازی خوشحال (انتخابی)!

منبع

This post is also available in Deutsch, English, Español, Français and English.