فصل ۲: قانون کانوی و چرایی اهمیت حیاتی آن در معماری

در سال ۱۹۶۸، ملوین کانوی، دانشمند علوم کامپیوتر، مقاله‌ای نوشت که مجله Harvard Business Review آن را به دلیل «اثبات نکردن فرضیات» رد کرد، اما بعدها به یکی از مهم‌ترین قوانین تاریخ مهندسی نرم‌افزار تبدیل شد. قانون کانوی بیان می‌کند: «سازمان‌هایی که سیستم‌ها را طراحی می‌کنند، ناگزیر به تولید طرح‌هایی هستند که کپیِ ساختارهای ارتباطیِ همان سازمان‌هاست.» به زبان ساده، اگر چهار گروه مجزا را مامور نوشتن یک کامپایلر کنید، خروجی نهایی شما قطعاً یک کامپایلر چهارمرحله‌ای (4-pass compiler) خواهد بود! دلیل این پدیده بسیار منطقی است: هر قطعه از نرم‌افزار که توسط یک تیم ساخته می‌شود، باید با قطعه ساخته‌شده توسط تیم دیگر ارتباط برقرار کند (Interface). این رابط نرم‌افزاری، تنها زمانی شکل می‌گیرد که دو تیم با یکدیگر مذاکره و تعامل کنند؛ بنابراین، معماری نهایی سیستم دقیقاً آینه مسیرهای ارتباطی (یا عدم ارتباط) میان تیم‌هاست.

سازمان‌هایی که سیستم‌ها را طراحی می‌کنند، محدود به تولید طراحی‌هایی هستند که رونوشتی از ساختارهای ارتباطی درون آن سازمان‌هاست.

نکته کلیدی در درک قانون کانوی، مفهوم هم‌ریختی (Homomorphism) میان گراف سازمان و گراف نرم‌افزار است. همان‌طور که روت مالان، معمار برجسته سیستم، اشاره می‌کند، اگر مدیران سازمان نسبت به این نیرو ناآگاه باشند، ساختارهای قدیمی، سیاسی و جزیره‌ای سازمان به طور خودکار خودشان را به درون کدهای نرم‌افزار تحمیل می‌کنند. شما نمی‌توانید یک معماری میکروسرویسِ چابک و مستقل داشته باشید، در حالی که تیم‌هایتان به صورت لایه‌ای (تیم فرانت‌اند، تیم بک‌اند، تیم دیتابیس) از هم جدا شده‌اند.

اگر قانون کانوی یک نیروی گریزناپذیر مانند جاذبه است، چگونه می‌توانیم از آن به نفع خودمان استفاده کنیم؟ پاسخ در تکنیکی به نام مانور معکوس کانوی (Inverse Conway Maneuver) نهفته است؛ اصطلاحی که نخستین بار توسط جونی لروی و مت سایمونز مطرح شد. به جای اینکه اجازه دهیم ساختار فعلی شرکت، معماری نرم‌افزار ما را خراب کند، ابتدا معماری نرم‌افزاری مطلوب و مورد نیاز کسب‌وکار را مشخص می‌کنیم و سپس ساختار تیم‌ها و مرزهای ارتباطی سازمان را طوری بازطراحی می‌کنیم که دقیقاً هم‌ریخت با آن معماری هدف باشد. به این ترتیب، قانون کانوی به جای یک مانع، به موتور محرکه‌ای تبدیل می‌شود که تیم‌ها را به طور طبیعی به سمت ساختن معماری درست هدایت می‌کند.

نویسندگان یک مثال کلاسیک و بسیار ملموس را کالبدشکافی می‌کنند: فرض کنید سه تیم محصول (فرانت‌اند و منطق دامنه) دارید، اما به دلیل سیاست‌های سنتی، تنها یک تیم متمرکز دیتابیس (DBA Team) اجازه تغییر جداول پایگاه داده را دارد. طبق قانون کانوی چه اتفاقی می‌افتد؟ چون هر سه تیم محصول برای ذخیره داده‌های خود باید با همان یک تیم DBA مذاکره کنند، تیم DBA برای راحتی کار خودش، تمام داده‌ها را در یک دیتابیس واحد و غول‌پیکر قرار می‌دهد و جداول مشترک می‌سازد. نتیجه چیست؟ هر سه محصول در لایه دیتابیس به هم قفل می‌شوند (Shared Database Anti-pattern) و هیچ تیمی نمی‌تواند بدون شکستن کار تیم دیگر، نسخه جدیدی را منتشر کند!

یکی از جسورانه‌ترین گزاره‌های این فصل آن است که طراحی سازمان (Organization Design) را نمی‌توان صرفاً به واحد منابع انسانی (HR) یا مشاوران مدیریت فاقد دانش فنی واگذار کرد. از آنجا که ساختار تیم‌ها مستقیماً معماری نرم‌افزار و پایداری سیستم‌های تولیدی را تعیین می‌کند، تغییر چارت سازمانی بدون درک مرزهای دامنه نرم‌افزار (Bounded Contexts) و وابستگی‌های فنی، مانند جراحی مغز با چشمان بسته است. مدیران ارشد فناوری (CTO)، معماران ارشد و رهبران مهندسی باید مستقیماً در طراحی مرزهای تیمی مشارکت داشته باشند.

در عین حال، نویسندگان نسبت به استفاده ساده‌لوحانه از قانون کانوی هشدار می‌دهند. اجرای مانور معکوس کانوی به این معنا نیست که هر میکروسرویس کوچک به یک تیم مجزا نیاز دارد (که منجر به انفجار هزینه و خرد شدن بیش از حد می‌شود) یا اینکه هر هفته با تغییر یک سرویس، اعضای تیم‌ها را جابه‌جا کنیم. طراحی تیم باید بر اساس «جریان‌های پایدار تغییر در دامنه کسب‌وکار» صورت گیرد، نه بر اساس تک‌تک کامپوننت‌های ریز کد.

اگر سازمان بر اساس عملکردهای تخصصی (مهندسی رابط کاربری، میان‌افزار، پایگاه داده) تفکیک شود، سیستم نهایی نیز در همان لایه‌ها شکاف برمی‌دارد و ادغام سرتاسری به کابوس تبدیل می‌شود.