اعترافات یک معمار نرم افزار، چرا نباید از روز اول رویای اسکیل شدن داشته باشیم؟

مرور سخنرانی : Master Software Architecture: From Simplicity to Complexity
سخنران : Maciej "MJ" Jedrzejewski

لینک یوتیوب:  https://www.youtube.com/watch?v=ZCrCqbblXjk

سخنران در ابتدای ارائه، یکی از اشتباهات رایج خودش را تعریف می کند: یک بار برای سایتی که روزانه فقط صد بازدیدکننده داشت، یک کلاستر کوبرنتیز راه اندازی کرده بود. نتیجه؟ بیشتر وقتش صرف دیباگ کردن پادها می شد تا توسعه ویژگی های جدید. او در این ویدیو دقیقا دست روی همان نقطه ضعف بزرگ مهندسان نرم افزار می گذارد: تله ی بیش مهندسی یا  Over-engineering

حرف حساب او این است که بهترین معماری، معماری ای است که مشکلات امروز شما را حل کند. او یک مسیر چهار مرحله ای را پیشنهاد می دهد: سادگی، قابلیت نگهداری، رشد، و پیچیدگی. در فاز اول (سادگی)، شما فقط باید محصول را به دست مشتری برسانید. هیچ نیازی به کافکا یا ردیس کلاستر نیست. وقتی ترافیک بالا رفت و کدها شروع به درهم تنیدگی کردند، تازه وارد فاز قابلیت نگهداری می شوید.

قسمتی از این ارائه که به شدت کاربردی است، تأکید بر کشف دامنه (Domain Discovery) بود. خیلی وقت ها ما بدون اینکه فرایند کسب وکار را بفهمیم، شروع به کشیدن دیاگرام پایگاه داده می کنیم. سخنران پیشنهاد می کند با تکنیک هایی مثل  Event Storming، متخصصان فنی و غیرفنی را دور هم جمع کنیم تا رویدادهای واقعی کسب وکار را روی تخته ترسیم کنند. این کار به صورت جادویی مرزهای سیستم را برای ما روشن می کند.

خلاصه برداشت من:
بزرگترین درس این ارائه ، غلبه بر ترس از جا ماندن در تکنولوژی بود. یاد گرفتم که معماری باید قدم به قدم با نیازهای واقعی کسب وکار رشد کند. تحمیل کردن میکروسرویس به سیستمی که هنوز ترافیک بالایی ندارد، هنر نیست، بلکه یک اشتباه مهندسی و تحمیل بدهی فنی است.

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