مشخصات سخنرانی:
عنوان: Master Software Architecture: From Simplicity to Complexity
سخنران: Maciej «MJ» Jedrzejewski
لینک ویدیو: مشاهده در یوتیوب
این سخنرانی با به چالش کشیدن نگاه سنتی به معماری نرمافزار آغاز میشود. برخلاف تصور رایج که معماری را یک نقشه کامل و از پیش طراحی شده (مانند روش آبشاری) میبیند، «MJ» آن را یک تایملاین از تصمیمات میداند. او معماری را به دو بخش سخت تقسیم میکند: «سختی در ساخت» به دلیل اطلاعات ناقص در شروع پروژه، و «سختی در تغییر» به این دلیل که تصمیمات اولیه در تار و پود مدلهای داده، ساختار تیمها و فرآیندهای سازمانی تنیده میشوند.
۱. پارادوکس پروژه و دام تکنولوژی یکی از مفاهیم کلیدی مطرح شده، «پارادوکس پروژه» است؛ یعنی ما باید حیاتیترین تصمیمات معماری را دقیقاً در روز اول بگیریم، یعنی زمانی که کمترین دانش را درباره رفتار کاربران، مقیاس واقعی و جزئیات بیزنس داریم. بسیاری از تیمها برای جبران این جهل، به دام «ترس از عقب ماندن» (FOMO) میافتند و از همان ابتدا سراغ ابزارهای پیچیدهای مثل میکروسرویسها یا کوبرنتیز میروند، غافل از اینکه با انتخاب یک ابزار، تمام مشکلات و پیچیدگیهای عملیاتی آن را نیز به جان میخرند.
۲. کشف دامنه کسبوکار (Business Domain) سخنران تأکید دارد که پیش از انتخاب هر تکنولوژی، باید بیزنس را درک کرد. او تکنیکهایی مانند Event Storming (برای یافتن وقایع بیزنس) و Domain Storytelling (برای درک جریان کار از زبان کارشناسان دامنه) را پیشنهاد میدهد. هدف این است که مرزهای سیستم (Bounded Contexts) بر اساس واقعیتهای کسبوکار شکل بگیرد، نه بر اساس لایههای تکنولوژی. همچنین ابزارهایی مثل «ماتریس شایستگی» برای سنجش توانایی واقعی تیم و در نظر گرفتن محدودیتهای بودجه و ددلاین، از پیشنیازهای حیاتی قبل از طراحی هستند.
۳. مدل چهار مرحلهای تکامل معماری هسته اصلی سخنرانی، معرفی یک چارچوب چهار مرحلهای برای رشد طبیعی سیستم است:
مرحله اول؛ سادگی (Simplicity): در شروع، هدف باید تحویل سریع ارزش به بازار باشد. توصیه میشود از یک مونولیت ماژولار (Modular Monolith) استفاده شود. کدها باید در بستههای منطقی جدا باشند و حتی در پایگاه داده، از «طرحوارههای منطقی» (Schemas) مجزا استفاده شود تا در آینده امکان تفکیک وجود داشته باشد، اما نباید درگیر پیچیدگیهای توزیعشدگی شد.
مرحله دوم؛ قابلیت نگهداری (Maintainability): پس از ورود به بازار و دریافت بازخورد، نقاط درد مشخص میشوند. در این مرحله، تیمها بزرگتر شده و ممکن است روی کدهای یکدیگر تأثیر منفی بگذارند. اینجا زمان بازنگری در ساختار، بهبود الگوهای ارتباطی (مثل استفاده از Inbox/Outbox) و جدا کردن پروژههاست.
مرحله سوم؛ رشد (Growth): تنها زمانی که ترافیک سیستم به شدت بالا میرود و هزینههای زیرساخت یا کندی سیستم به یک مشکل واقعی تبدیل میشود، استخراج میکروسرویسها توجیه پیدا میکند. پیچیدگی مقیاسپذیری، پاداشی است که فقط برای سیستمهای موفق پرداخت میشود.
مرحله چهارم؛ پیچیدگی (Complexity): در نهایت، زمانی که قوانین کسبوکار یا مقررات دولتی بسیار پیچیده میشوند، باید از الگوهای پیشرفتهتری مثل DDD (طراحی دامنه-محور) و Aggregateها برای مدیریت انسجام دادهها استفاده کرد.
۴. درسهایی از شکستهای واقعی سخنران با صداقت به اشتباهات خود اشاره میکند تا دیگران آنها را تکرار نکنند؛ اشتباهاتی مثل استفاده از کش (Cache) بدون بهینهسازی دیتابیس که فقط لایهای از پیچیدگی و کابوسِ نامعتبرسازی داده را اضافه میکند، یا پیادهسازی میکروسرویس برای سیستمی که تعداد سرویسهایش از تعداد کاربرانش بیشتر بود! همچنین او به هزینههای سرسامآور لاگگرفتن بیهوده در محیط عملیاتی اشاره میکند که گاهی از هزینه کل پردازش سیستم فراتر میرود.
پیام محوری این است: برای سیستمی که آرزو دارید سه سال دیگر داشته باشید معماری نکنید، بلکه برای نیازهای همین فصل طراحی کنید. بهترین معماری آن نیست که از مدرنترین ابزارها استفاده کند، بلکه آن است که با کمترین هزینه و پیچیدگی، مشکلات فعلی را حل کرده و در عین حال، درهای تغییر را برای آینده باز نگه دارد. معماری نرمافزار، هنرِ «به تعویق انداختن تصمیمات غیرضروری» است تا زمانی که دانش کافی برای اتخاذ آنها حاصل شود.
اين مطلب، بخشي از تمرينهاي درس معماري نرمافزار در دانشگاه شهيدبهشتي اس
