معماری خوب از پیچیدگی شروع نمی‌شود؛ با نیاز واقعی رشد می‌کند

عنوان سخنرانی: Master Software Architecture: From Simplicity to Complexity
سخنران: Maciej “MJ” Jedrzejewski
همایش: GOTO Copenhagen 2025
مدت سخنرانی: حدود ۴۶ دقیقه
لینک ویدئو: https://youtu.be/ZCrCqbblXjk?si=MEnV_fgd6H-6pSw9

وقتی درباره معماری نرم‌افزار صحبت می‌کنیم، معمولا اولین چیزهایی که به ذهن می‌رسد میکروسرویس، معماری رویدادمحور، Kubernetes، صف پیام و پایگاه‌ داده‌های توزیع‌ شده هستند. با این حال، سخنرانی «تسلط بر معماری نرم‌افزار؛ از سادگی تا پیچیدگی» به این موضوع اشاره دارد که معماری خوب الزاما معماری پیچیده نیست. به نظر سخنران، معماری نرم‌افزار یک طرح ثابت و نهایی نیست که در ابتدای پروژه طراحی شود و تا پایان بدون تغییر باقی بماند؛ بلکه ساختاری زنده و تکامل‌یابنده است که باید همراه با نیازهای کسب‌وکار، رشد کاربران، تغییرات تیم و محدودیت‌های محیطی تغییر کند.

یکی از نکات مهم سخنرانی این است که پیچیدگی نباید پیش از آنکه واقعا به آن نیاز داشته باشیم، وارد سیستم شود. گاهی تیم‌های توسعه برای حل مشکلاتی که هنوز وجود ندارند، از همان ابتدای پروژه سراغ معماری‌های توزیع‌شده، سرویس‌های متعدد و ابزارهای پیشرفته می‌روند. این تصمیم ممکن است در ظاهر حرفه‌ای به نظر برسد، اما در عمل هزینه توسعه، استقرار، تست، مانیتورینگ و رفع خطا را افزایش می‌دهد. سخنران با اشاره به تجربه پروژه‌های واقعی توضیح می‌دهد که در برخی موارد، تیم‌ها سیستم‌های توزیع‌شده‌ای ساخته‌اند که اساسا نیازی به توزیع‌شدن نداشته‌اند یا مؤلفه‌هایی به معماری اضافه کرده‌اند که تنها مسائل فرضی را حل می‌کردند.

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

سخنران مسیر تکامل معماری را با چهار مفهوم اصلی سادگی، نگهداشت‌پذیری، رشد و پیچیدگی توضیح می‌دهد. در مرحله سادگی، هدف این است که سیستم با کمترین پیچیدگی ضروری ساخته شود و ارزش موردنیاز را سریع‌تر در اختیار کاربر قرار دهد. با رشد محصول، نگهداشت‌ پذیری اهمیت بیشتری پیدا می‌کند؛ یعنی زمانی که تیم برای اضافه‌کردن قابلیت‌های جدید بیش از حد با ساختار موجود درگیر می‌شود، باید مرز ماژول‌ها، وابستگی‌ها و نحوه سازمان‌دهی کد بازبینی شود. در مرحله رشد نیز ابزارهایی مانند کش، نسخه‌های خواندنی پایگاه‌داده، ماژولارکردن سیستم یا میکروسرویس‌ها زمانی ارزشمند می‌شوند که یک مشکل واقعی در مقیاس، عملکرد یا استقلال تیم‌ها وجود داشته باشد. در نهایت، پیچیدگی‌های سنگین‌تر مانند قوانین خاص، پردازش‌های توزیع‌شده یا منطق دامنه پیشرفته باید در پاسخ به نیازهای واقعی وارد معماری شوند، نه صرفاً به دلیل محبوب‌بودن یک فناوری.

موضوع مهم دیگر، نقش استقرار، انتشار و تست در تکامل معماری است. من پیش از دیدن این سخنرانی بیشتر به تست به‌ عنوان ابزاری برای پیداکردن خطا نگاه می‌کردم؛ اما در این ارائه، تست به‌ عنوان شبکه ایمنی تغییر معرفی می‌شود. زمانی می‌توان یک معماری ساده را با اطمینان به ساختاری کامل‌تر تبدیل کرد که تست‌های مناسب، بازخورد سریع و فرایند انتشار کنترل‌شده وجود داشته باشند. استراتژی‌های مناسب استقرار و انتشار نیز تشریفات اضافی نیستند؛ بلکه کمک می‌کنند تغییرات معماری به‌صورت تدریجی، قابل‌کنترل و با ریسک کمتر انجام شوند.

سخنران همچنین تاکید می‌کند که امنیت نباید قابلیتی باشد که پس از کامل‌ شدن سیستم به آن اضافه شود. امنیت باید در تمام مراحل تکامل معماری، از ساده‌ترین نسخه تا پیچیده‌ترین حالت، موردتوجه قرار گیرد. به‌تعویق‌انداختن تصمیم‌های امنیتی می‌تواند باعث ایجاد بدهی فنی شود که اصلاح آن در آینده بسیار پرهزینه‌تر خواهد بود.

به نظر من، نقطه قوت اصلی این سخنرانی، نگاه واقع‌ گرایانه و غیرابزارمحور آن به معماری است. این ارائه تلاش نمی‌کند یک سبک معماری را برای همه پروژه‌ها مناسب معرفی کند. پیام آن این است که انتخاب معماری باید از شناخت مسئله، دامنه کسب‌وکار، محدودیت‌ها، توانایی تیم و شواهد واقعی حاصل شود. البته به دلیل گستردگی موضوعات، درباره برخی تکنیک‌ها جزئیات اجرایی زیادی ارائه نمی‌شود؛ اما هدف سخنرانی نیز آموزش یک فناوری خاص نیست، بلکه اصلاح شیوه فکرکردن درباره تصمیم‌های معماری است.

در نهایت، مهم‌ترین نتیجه‌ای که من از این سخنرانی گرفتم این است که وظیفه معمار، ساختن پیچیده‌ترین سیستم ممکن نیست. معمار خوب کسی است که پیچیدگی ضروری را از پیچیدگی نمایشی تشخیص دهد، تا جای ممکن تصمیم‌های برگشت‌ناپذیر را به تعویق بیندازد و شرایطی فراهم کند که سیستم بتواند بدون فروپاشی رشد کند. معماری موفق معماری‌ای نیست که از روز اول برای تمام آینده آماده باشد؛ بلکه معماری‌ای است که امروز قابل‌فهم و مفید باشد و فردا نیز بتوان آن را با هزینه‌ای منطقی تغییر داد.

منابع

• ویدئوی رسمی سخنرانی در کانال GOTO Conferences :
  https://youtu.be/ZCrCqbblXjk?si=MEnV_fgd6H-6pSw9

• صفحه رسمی سخنرانی در GOTO :
  https://gotopia.tech/sessions/3660/master-software-architecture-from-simplicity-to-complexity

• صفحه سخنران در GOTO Copenhagen 2025 :
  https://gotocph.com/2025/speakers/3894/maciej-jedrzejewski

• معرفی کتاب Master Software Architecture: A Pragmatic Guide :

  https://mastersoftwarearchitecturebook.com

اين مطلب، بخشی از تمرين‌های درس معماری نرم‌افزار در دانشگاه شهيدبهشتی است 🌱