معماری نرم افزار حوزه ای است که دائماً تحت تأثیر تجربه های واقعی صنعت، فناوریه ای جدید و تغییر شیوه های توسعه قرار می گیرد. به همین دلیل، سخنرانی های کنفرانس هایی مانند GOTO یکی از بهترین منابع برای آشنایی با دیدگاه های معماران و مهندسان باتجربه به شمار می روند؛ افرادی که بسیاری از ایده های مطرح شده را در پروژه های واقعی و در مقیاس بزرگ به کار گرفته اند.
در این مطلب، مروری بر پنج سخنرانی مرتبط با معماری نرم افزار ارائه شده و در هر بخش، تلاش شده ضمن بیان ایده های اصلی، به مثالهای مهم، مفاهیم کلیدی و برداشت شخصی خود نیز اشاره کرده تا ارتباط این مباحث با درس معماری نرم افزار روشن تر شود.
Data: The Land DevOps Forgot
Michael Nygard
GOTO 2024
https://www.youtube.com/watch?v=SfIvrtDsE3Q
Michael Nygard در این سخنرانی سراغ بخشی از مهندسی نرم افزار می رود که معمولاً در گفتگوهای DevOps کمتر از آن حرف زده می شود: داده. پیام اصلی او این است که اگرچه DevOps توانسته چرخه توسعه و استقرار نرم افزار را متحول کند، اما همان منطق و همان ابزار را نمی توان بدون تغییر، مستقیماً به دنیای داده و تحلیل منتقل کرد. او با مثال های واقعی از Nubank نشان می دهد که سیستم های داده ای در مقیاس بزرگ، منطق عملیاتی متفاوتی دارند؛ از تأخیرهای طولانی در پردازش گرفته تا هزینه ی بالای تغییر؛ همین تفاوت ها باعث می شود که معماری داده نیازمند نگاه مستقل باشد.
یکی از نکات مهم سخنرانی، تفاوت بین دنیای تراکنشی و دنیای تحلیلی است. در سیستمهای تراکنشی، تغییرات معمولاً در چند دقیقه یا چند ثانیه اثر میگذارند و خطاها سریع دیده میشوند، ولی در سیستمهای تحلیلی، یک تغییر ممکن است ساعتها یا حتی روزها بعد خودش را نشان دهد. این فاصلهی زمانی، هم اشکالزدایی را سختتر میکند و هم هزینهی تصمیمهای معماری را بالا میبرد. به همین دلیل نایگارد تأکید میکند که مدیریت داده فقط یک مسئلهی فنی نیست، بلکه به سازمان، مالکیت، شفافیت و اعتماد هم وابسته است.
مفهوم Data Mesh در این سخنرانی بهخوبی برجسته میشود. او توضیح میدهد که داده باید مانند یک محصول دیده شود، نه صرفاً یک خروجی خام از سیستمها. وقتی داده محصول است، باید مالک داشته باشد، کیفیتش قابل سنجش باشد، مسیر تولیدش مشخص باشد و مصرفکننده بتواند به آن اعتماد کند. این دیدگاه برای من بسیار مهم بود، چون نشان میدهد که در معماری نرمافزار، مرزها و مسئولیتها به اندازهی انتخاب فناوری اهمیت دارند. اگر تیمها فقط تولیدکننده داده باشند و هیچ حس مالکیتی نسبت به کیفیت و مصرف آن نداشته باشند، پیچیدگی سیستم بهمرور از کنترل خارج میشود.
از منظر درس معماری نرمافزار، این سخنرانی یک نمونهی روشن از معماری socio-technical است؛ یعنی جایی که طراحی فنی و طراحی سازمانی به هم گره خوردهاند. Data Mesh بدون تغییر در مدل همکاری تیمها، ساختار مالکیت، و ساز و کارهای governance عملاً کار نمیکند. بنابراین معماری موفق فقط در کد تعریف نمیشود، بلکه در نحوهی هماهنگی آدمها، تیمها و تصمیمها هم شکل میگیرد.
نقطه قوت این سخنرانی در واقعگرایی آن است. نایگارد ایدههایش را در قالب تجربهی عملی و واقعی و هزینههای ملموس توضیح میدهد. پیام اصلی سخنرانی بسیار روشن است: اگر داده را جدی نگیریم، حتی بهترین معماری نرمافزار هم در عمل شکننده خواهد بود.
Tidy First? A Daily Exercise in Empirical Design
Kent Beck
GOTO 2024
https://www.youtube.com/watch?v=Saaz6D1azlU
Kent Beck در این سخنرانی، معماری و طراحی نرمافزار را از زاویهای بسیار انسانی و در عین حال دقیق توضیح میدهد. او بحث را از یک سؤال ساده شروع میکند: وقتی با یک تکه کد نامرتب روبهرو میشویم، آیا باید اول آن را مرتب کنیم یا مستقیم سراغ تغییر رفتار برویم؟ همین سؤال، کوچکترین واحد تصمیمگیری در طراحی نرمافزار است. عنوان Tidy First دقیقاً به همین لحظه اشاره دارد؛ لحظهای که باید تصمیم بگیریم قبل از اعمال feature، ساختار را بهتر کنیم یا نه.
آنچه این سخنرانی بسیار جذاب است، این است که بک طراحی نرمافزار را نه یک فعالیت انتزاعی، بلکه یک کنش روزمره و بسیار عملی نشان میدهد. او میگوید طراحی نرمافزار در اصل برای تغییر دادن نرمافزار است؛ اگر قرار نیست چیزی تغییر کند، اهمیت طراحی هم بسیار کمتر میشود؛ اما چون نرمافزار دائماً در حال تغییر است، ساختار داخلی آن تعیین میکند که این تغییر چقدر آسان، چقدر پرهزینه و چقدر امن خواهد بود. اینجا ایدهی technical debt دوباره معنا پیدا میکند: مشکل فقط این نیست که کد بد نوشته شده، بلکه این است که ساختار بد، هزینهی تغییر را بهمرور بالا میبرد.
بک در ادامه توضیح میدهد که چرا سرمایهگذاری در ساختار معمولاً کمتر از چیزی است که باید باشد. featureها قابل دیدن هستند، اما ساختار نه. کاربران و مدیران نتیجهی feature را میبینند، اما هزینهی پنهان ساختار را معمولاً وقتی میفهمند که دیگر دیر شده است، توسعه کند شده، defectها بیشتر شده و تیم برای هر تغییر کوچک، باید مسیر طولانیتری را طی کند.
این بخش از سخنرانی بهخوبی نشان میدهد که معماری صرفاً به زیبایی کد یا اصول انتزاعی مربوط نیست، بلکه مستقیماً به اقتصاد تغییر در نرمافزار مرتبط است.
مثالهای او دربارهی payroll calculator و تجربهی ساخت دو نسخهی موازی از یک قابلیت، خیلی خوب این مفهوم را جا میاندازد که گاهی یک تصمیم ساختاری در آینده فرصتهای جدیدی ایجاد میکند. یعنی یک refactoring یا سادهسازی ساختار، بعداً featureهایی را ممکن میکند که قبلاً بسیار پرهزینه بودند. این همان چیزی است که بک آن را نوعی بازده غیرخطی در نرمافزار میداند. این نگاه نشان میدهد architecture فقط برای جلوگیری از مشکل نیست؛ گاهی برای خلق فرصتهای جدید هم هست.
نکتهی مهم دیگر، نگاه او به رابطهی انسانی در طراحی است. بک به صراحت میگوید که software design فقط دربارهی کد نیست، بلکه دربارهی رابطهی انسانها، اعتماد، انگیزهها و همکاری تیمی هم هست. این موضوع را میتوان در سطح architecture هم دید؛ اگر design decisions بدون توجه به social structure گرفته شوند، همانقدر شکست میخورند که یک abstraction بد در کد. در نتیجه، این سخنرانی، یک یادآوری مهم بود که معماری خوب، ترکیبی از reasoning فنی، تجربهی عملی و درک انسانی است.
Microservices, Where Did It All Go Wrong
Ian Cooper
GOTO 2024
https://www.youtube.com/watch?v=j2AQ9eTZ3-0
این سخنرانی یکی از دقیقترین و در عین حال انتقادیترین صحبتها دربارهی Microservices است. Ian Cooper با این پیشفرض شروع نمیکند که Microservices بد هستند؛ برعکس، او میپذیرد که این سبک معماری در بسیاری از زمینهها مزایای واقعی دارد. پرسش اصلی او این است که چرا در عمل، خیلی از پیادهسازیهای Microservices بهجای کاهش پیچیدگی، آن را چند برابر کردهاند. پاسخ او ساده نیست، چون از یک خطای رایج شروع میشود: اشتباه گرفتن micro با کوچک بودنِ صرف، و اشتباه گرفتن service با process.
نخستین بخش مهم سخنرانی، بازگشت به تعریفهای کلاسیک است. او توضیح میدهد که module، component، service و microservice هر کدام معنای خاص خود را دارند و نمیتوان آنها را بهجای هم استفاده کرد. microservice قرار نیست فقط یک سرویس خیلی کوچک باشد؛ بلکه باید قابل تفکیک، قابل جایگزینی و manageably small باشد. این distinction بسیار مهم است، چون نشان میدهد بسیاری از مشکلات معماری از واژههایی میآیند که در تیمها دقیق تعریف نشدهاند. وقتی مفهوم service به process، container یا pod تقلیل پیدا کند، کل طراحی از ریشه منحرف میشود.
کوپر با مثالهای متعدد نشان میدهد که وقتی تعداد سرویسها بیش از حد زیاد شود، هزینهی coordination، latency، observability و deployment بهشدت بالا میرود. او بارها تأکید میکند که زیاد کردن تعداد سرویسها لزوماً باعث loose coupling نمیشود؛ در بسیاری از موارد، نتیجهی برعکس دارد: cohesion پایین میآید، coupling واقعی بیشتر میشود و هر change کوچک به shotgun surgery تبدیل میشود. رایجترین تصور دربارهی Microservices دقیقاً همین است که کوچکتر کردن همیشه مفید است، در حالی که او نشان میدهد یک sweet spot وجود دارد و عبور از آن، معماری را بدتر میکند.
بخش جالب دیگر، نقد او به استفادهی کورکورانه از Kubernetes و containerization است. او میگوید اگر هر service را صرفاً یک container ببینیم، در واقع از معماری به سمت ابزارمحوری لغزیدهایم. یعنی بهجای اینکه مسئلهی دامنه، استقلال تیم، یا قابلیت تغییر را حل کنیم، فقط زیرساخت را پیچیدهتر کردهایم. این نقد، تفاوت architecture با infrastructure را برجسته میکند. معماری با فرایندهای تجاری، مرزهای دامنه و قابلیت reasoning سروکار دارد، نه فقط با نحوهی اجرای deployment.
نقطه قوت سخنرانی این است که هم از تجربهی صنعتی استفاده میکند و هم از مبانی نظری. او بهجای شعار، به تفکیک هزینهها، coupling، cohesion و محدودیتهای واقعی سازمانها برمیگردد.
Architecture Isn’t Kubernetes
Diana Montalion
GOTO 2024
https://www.youtube.com/watch?v=v50oJao8W1Y
این سخنرانی از آن صحبتهایی است که در ظاهر دربارهی architecture است، اما در عمق، دربارهی شیوهی تفکر است. Diana Montalion با این جملهی کلیدی شروع میکند که architecture را نباید با Kubernetes، cloud-native tooling یا technology stack اشتباه گرفت. بهنظر او، مشکل بسیاری از سازمانها این است که وقتی از architectural modernization حرف میزنند، در عمل منظورشان صرفاً تعویض ابزارهاست؛ در حالی که معماری واقعی، بیش از هر چیز، به نوع reasoning، الگوی تصمیمگیری و روابط انسانی داخل سازمان وابسته است.
یکی از محورهای اصلی سخنرانی، systems thinking است. او توضیح میدهد که تفکر خطی و reductionist برای بخشی از مسائل خوب است، اما برای سیستمهای پیچیده کافی نیست و تأکید میکند که معمار نرمافزار باید بتواند بین تحلیل جزءنگر و نگاه سیستمی جابهجا شود. این ایده بسیار مهم است، چون در معماری مدرن، اغلب وسوسه میشویم مسئله را به تکنولوژی تقلیل دهیم؛ مثلاً فکر کنیم اگر به cloud برویم، اگر از microservices استفاده کنیم، یا اگر Kubernetes داشته باشیم، معماری درست میشود. در حالی که او نشان میدهد ابزار فقط بخشی از مسئله است، نه خود مسئله.
نکتهی مهم دیگر، توجه به metacognition است؛ یعنی اینکه معمار نهتنها باید دربارهی سیستم فکر کند، بلکه باید دربارهی شیوهی فکر کردن خودش هم آگاه باشد. او با مثالهایی از fallacyها، straw man، و reactionهای غیرسازنده نشان میدهد که بسیاری از خطاهای معماری، قبل از اینکه در code رخ دهند، در reasoning رخ دادهاند. این دیدگاه بسیار بالغ است، چون معماری را از سطح recommendation دادن دربارهی technology stack بالاتر میبرد و آن را به یک practice مبتنی بر قضاوت، تأمل و تعامل تبدیل میکند.
مهمترین پیام سخنرانی این است که architecture یک کار ثابت نیست، بلکه practiceی است که دائماً باید در حال رشد باشد. او میگوید شرایط، تیمها، تکنولوژی و مسئلهها دائماً تغییر میکنند و بنابراین هیچ معماریای برای همیشه تمامشده نیست. این حرف، هم ساده است و هم بسیار عمیق. این سخنرانی یادآوری میکند که معماری بیشتر با uncertainty، trade-off و continuous learning سر و کار دارد.
این ویدیو مخاطب را از یک نگاه ابزارمحور بیرون میکشد و دوباره به اصل architecture برمیگرداند: سازمان، تصمیم، رابطه، و توانایی دیدن سیستم بهصورت کلنگر. اگر کسی بخواهد معماری را فقط بهعنوان deployment platform بفهمد، این سخنرانی بهخوبی نشان میدهد که آن نگاه ناقص است.
Architecture aspects - evolutionary architecture development
Urs Enzler
https://www.youtube.com/watch?v=3yZv6oDfY9E
سخنرانی Urs Enzler دربارهی evolutionary architecture یکی از عملیترین صحبتهایی است که میشود در حوزهی معماری نرمافزار دید. پیام مرکزی او این است که architecture نباید از ابتدا بهصورت یک طرح کامل و نهایی تصور شود؛ بلکه باید در طول زمان، همراه با رشد محصول، تغییر نیازها و بازخورد کاربران تکامل پیدا کند. او با مثالهایی از یک سیستم واقعی نشان میدهد که تصمیمهای معماری معمولاً باید مرحله به مرحله و با در نظر گرفتن اطلاعاتی که در هر مرحله بهدست میآید، گرفته شوند.
یکی از نکات قابل توجه سخنرانی، تأکید او بر این است که در شروع یک پروژه، over-engineering خطرناک است. وقتی سیستم هنوز کوچک است، رفتن مستقیم به سمت microservices، layering پیچیده یا abstractionهای سنگین معمولاً بیشتر از اینکه مفید باشد، باعث پیچیدگی زودهنگام میشود. او پیشنهاد میکند که در ابتدا ساده شروع کنیم، اما در عین حال از همان ابتدا طوری تصمیم بگیریم که مسیر تکامل در آینده بسته نشود. این نگاه دقیقاً همان چیزی است که در معماری خوب لازم داریم: سادگی امروز، همراه با قابلیت رشد فردا.
بخش مهم دیگر، بحث persistence و storage است. Enzler با مقایسهی CRUD، history-based approaches و event sourcing نشان میدهد که هر انتخاب معماری یک trade-off واقعی دارد. اگر فقط current state را ذخیره کنیم، تغییرات سادهتر میشوند؛ اما اگر تاریخچه مهم باشد، event sourcing میتواند ارزشمندتر باشد. در عین حال، او به درستی هشدار میدهد که event sourcing هم همیشه جواب نیست و snapshot، read model یا cache هر کدام در سناریوی مناسب خود معنا دارند. این، معماری را از حالت شعاری خارج میکند و به یک series of decisions مبتنی بر context تبدیل میکند.
موضوع layering و modularization هم در سخنرانی جایگاه مهمی دارد. او میگوید که در ابتدا لازم نیست با microservices شروع کنیم؛ بهتر است اول domain را بفهمیم، بعد subsystems را پیدا کنیم، سپس اگر سیستم رشد کرد، به hexagonal architecture، clean architecture یا در نهایت microservices فکر کنیم. این سیر تکاملی نشان میدهد architecture maturity باید متناسب با maturity خود سیستم باشد. یعنی معماری خوب، معماریای نیست که از روز اول پیچیدهترین شکل را داشته باشد، بلکه معماریای است که در هر مرحله، درستترین سطح از سازماندهی را ارائه میدهد.
بنابراین، evolutionary architecture یک رویکرد واقعبینانه، اقتصادی و حرفهای است. بهجای اینکه همه چیز را از ابتدا قطعی و ثابت فرض کنیم، باید سیستم را بهصورت زنده، قابلتغییر و باز به سمت آینده ببینیم. این نگاه، هم با تجربهی صنعتی سازگار است و هم با اصل بنیادین معماری نرمافزار که میگوید: بهترین طراحی، طراحیای است که تغییر را ممکن و ارزان نگه میدارد.
مطالعه و بررسی این سخنرانیها نشان میدهد که معماری نرمافزار تنها به انتخاب فناوری یا ابزار محدود نمیشود، بلکه بیش از هر چیز به شیوهی تفکر، تصمیمگیری و مدیریت تغییر وابسته است. با وجود تفاوت موضوعات، همه سخنرانان بر مفاهیمی مانند Evolutionary Architecture، Modularity، Trade-off، کاهش Coupling و اهمیت عوامل انسانی در طراحی سیستمها تأکید داشتند.
بنابراین، معماری خوب، معماریای است که در برابر تغییرات آینده انعطافپذیر باشد و بتواند همزمان نیازهای فنی، کسبوکار و تیم توسعه را بهخوبی متعادل کند.
«اين مطلب، بخشي از تمرين درس معماري نرمافزار دانشگاه شهيد بهشتی است.»
