معماری نرم‌افزار در عمل؛ درس‌هایی از ۵ سخنرانی بین‌المللی

عنوان سخنرانی: Thinking Like an Architect

سخنران: Gregor Hohpe

لینک ویدیو: https://youtu.be/xtxfrxf0mfE?si=7gXf5PgBFdhdkEl6

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

عنوان سخنرانی: Architecture Isn't Kubernetes: Five Essential Practices of a Modern Systems Architect

سخنران: Diana Montalion

لینک ویدیو: https://youtu.be/v50oJao8W1Y?si=dHlbD268HMj6q0Zq

او می‌خواهد نشان دهد که معماری نرم‌افزار بسیار فراتر از یادگیری یک فناوری یا ابزار خاص است و یک معمار موفق باید بیشتر روی نحوه تفکر و تحلیل مسائل تمرکز کند تا روی ابزارهایی که هر چند سال یک‌بار تغییر می‌کنند.
او در ابتدای ارائه از تجربه شخصی خود صحبت می‌کند و توضیح می‌دهد که بارها در پروژه‌های بزرگ تحول دیجیتال حضور داشته است. بسیاری از شرکت‌ها تصور می‌کردند با مهاجرت به  Cloud، استفاده از Kubernetes یا معماری Cloud Native تمام مشکلاتشان حل خواهد شد، اما در عمل پروژه‌ها با شکست یا مشکلات جدی روبه‌رو می‌شدند. به نظر او دلیل اصلی این موضوع، فناوری نبود، بلکه ساختار سازمان، نحوه همکاری تیم‌ها و شیوه تفکر افراد بود.
یکی از مهم‌ترین بخش‌های سخنرانی، توضیح درباره قانون Conway بود. وی بیان کرد که ساختار نرم‌افزار معمولاً بازتابی از ساختار ارتباطی سازمان است. یعنی اگر ارتباط بین تیم‌ها ضعیف باشد، این ضعف در معماری سیستم نیز دیده خواهد شد. قبلاً این قانون را فقط در کتاب‌ها خوانده بودم، اما مثال‌هایی که در این ارائه مطرح شد باعث شد کاربرد عملی آن را بهتر درک کنم.
بعد از آن، Diana Montalion پنج مهارت اصلی یک معمار مدرن را معرفی کرد. اولین مهارت، داشتن نگاه سیستمی   (Systems Thinking)  بود. او توضیح داد که ما معمولاً مشکلات را به بخش‌های کوچک تقسیم می‌کنیم، اما همیشه نمی‌توان با بررسی تک‌تک قسمت‌ها رفتار کل سیستم را فهمید. گاهی روابط بین اجزا اهمیت بیشتری از خود اجزا دارند.
مهارت دوم، شناخت شیوه تفکر خود یا Metacognition بود. Diana تأکید می‌کرد که معمار باید بداند چگونه فکر می‌کند، چه پیش‌فرض‌هایی دارد و ممکن است در چه مواردی دچار خطای ذهنی شود. او چند نمونه از خطاهای رایج در جلسات معماری را مطرح کرد؛ مثلاً اینکه افراد به جای بررسی یک پیشنهاد، فقط بر اساس تجربه شخصی یا اعتبار گوینده آن را رد یا قبول می‌کنند.
در ادامه درباره Systemic Reasoning صحبت شد. منظور از این مفهوم این است که هنگام ارائه یک راه‌حل، فقط نباید نظر شخصی خود را بیان کنیم، بلکه باید بتوانیم با دلیل، شواهد و تحلیل منطقی از آن دفاع کنیم. او معتقد بود معماری صرفاً بیان نظر نیست، بلکه فرآیندی برای رسیدن به بهترین تصمیم در شرایطی است که همیشه مقداری عدم قطعیت وجود دارد. این دیدگاه باعث شد متوجه شوم تصمیم‌گیری در معماری بیشتر از آنکه به تجربه وابسته باشد، به استدلال صحیح وابسته است.
از دیگر نکات مهم سخنرانی، توجه به روابط بین اجزای سیستم بود Diana Montalion می گوید که بسیاری از مشکلات نرم‌افزار نه در کد، بلکه در ارتباط بین سرویس‌ها، تیم‌ها و فرایندهای سازمانی ایجاد می‌شود. او جمله‌ای نقل کرد که مفهوم آن این بود که «یک سیستم فقط مجموع اجزای آن نیست، بلکه حاصل تعامل بین آن اجزاست.»
در بخش پایانی نیز وی درباره تغییر پارادایم صحبت کرد. او اعتقاد داشت بسیاری از سازمان‌ها تلاش می‌کنند با ابزارهای جدید، همان شیوه قدیمی کار را ادامه دهند. به همین دلیل، حتی اگر از Microservices یا Kubernetes استفاده کنند، باز هم مشکلات قبلی تکرار می‌شود. از نظر او، برای تحول واقعی باید طرز فکر و فرهنگ سازمان نیز تغییر کند، نه فقط فناوری.

عنوان سخنرانی: Practical (a.k.a. Actually Useful) Architecture

سخنران: Stefan Tilkov

لینک ویدیو: https://youtu.be/v50oJao8W1Y?si=Rr01IX9ug9bN-Ynx

 Stefan Tilkov از همان ابتدای صحبت‌های خود اشاره می‌کند که قرار نیست صرفاً درباره تعریف معماری صحبت کند، بلکه هدف او توضیح دادن «کار واقعی یک معمار نرم‌افزار» است. همین موضوع باعث شد که ارائه بیشتر روی تجربه‌های عملی و چالش‌های واقعی پروژه‌ها تمرکز داشته باشد و فقط به بیان مفاهیم تئوری محدود نشود.
یکی از نکاتی که در طول سخنرانی چندین بار به آن اشاره شد، اهمیت درک شرایط هر پروژه بود. Stefan تأکید می‌کند که هیچ راه‌حل واحدی وجود ندارد که برای همه سیستم‌ها مناسب باشد. بسیاری از افراد به دنبال استفاده از جدیدترین فناوری‌ها یا الگوهای طراحی هستند، اما همیشه این انتخاب بهترین گزینه نیست. معماری خوب زمانی شکل می‌گیرد که تصمیم‌ها متناسب با نیازهای واقعی پروژه گرفته شوند، نه صرفاً بر اساس محبوب بودن یک فناوری.
یکی از بخش‌های جالب سخنرانی مربوط به صحبت درباره ابزارهای هوش مصنوعی مانند ChatGPT بود Stefan Tilko .با نشان دادن نمونه‌ای از پاسخ تولیدشده توسط هوش مصنوعی توضیح داد که این ابزارها می‌توانند نمودارها و معماری‌هایی تولید کنند که در ظاهر بسیار حرفه‌ای به نظر می‌رسند، اما در بسیاری از موارد فقط مجموعه‌ای از اصطلاحات و الگوهای رایج را کنار هم قرار می‌دهند. او معتقد بود اگر یک معمار فقط همان کار را انجام دهد و بدون تحلیل، الگوهای آماده را تکرار کند، تفاوت چندانی با یک مدل زبانی نخواهد داشت.
بخش دیگری که مورد توجه بود ، صحبت درباره استفاده بی‌دلیل از فناوری‌های جدید بود. او با مثال‌هایی مانند  Blockchain  توضیح داد که گاهی شرکت‌ها فقط به دلیل محبوب بودن یک فناوری به سراغ آن می‌روند، در حالی که ممکن است هیچ نیازی به آن نداشته باشند. او حتی با لحنی طنزآمیز اشاره کرد که گاهی استفاده از فناوری‌های پیچیده برای بعضی افراد سود مالی بیشتری دارد، اما این موضوع لزوماً به معنای بهتر بودن آن فناوری نیست.
یکی دیگر از پیام‌های مهم سخنرانی این بود که معمار نباید از مسائل کسب‌وکار فاصله بگیرد Stefan Tilkov.می گوید که بعضی از مهندسان ترجیح می‌دهند روی فناوری‌های جذاب یا مسائل فنی پیچیده کار کنند و کمتر به فرآیندهای تجاری توجه داشته باشند. اما واقعیت این است که هدف اصلی نرم‌افزار حل مسائل کسب‌وکار است و اگر معمار نیازهای واقعی سازمان را درک نکند، حتی بهترین طراحی فنی نیز ارزش چندانی نخواهد داشت. این بخش باعث شد متوجه شوم که شناخت دامنه کسب‌وکار یکی از مهم‌ترین وظایف یک معمار نرم‌افزار است.
در پایان، او چند توصیه مهم ارائه کرد که خلاصه کل سخنرانی بودند. او تأکید کرد که نباید به دنبال یک راه‌حل ثابت برای همه پروژه‌ها بود و همیشه باید شرایط و محدودیت‌های هر پروژه را بررسی کرد. همچنین هدف معماری نباید رسیدن به یک سیستم کاملاً بی‌نقص باشد، بلکه باید سیستمی طراحی شود که در آینده به‌راحتی قابل تغییر و توسعه باشد.

عنوان سخنرانی: Optimizing Organizational Flow with Wardley Mapping & DDD

سخنران: Susanne Kaiser & James Lewis

لینک ویدیو: https://youtu.be/Gs1zUKrFCoY?si=KDJj8ZScgLYHLVlh

معمولاً وقتی صحبت از معماری نرم‌افزار می‌شود، ذهن ما به سمت طراحی سیستم، میکروسرویس‌ها یا انتخاب فناوری‌ها می‌رود، اما Susanne Kaiser و James Lewis بیشتر روی ارتباط بین ساختار سازمان، تیم‌ها و معماری نرم‌افزار تمرکز کردند.
در این ارائه، سخنرانان توضیح دادند که ابزارهایی مانند  Wardley Mapping وDomain-Driven Design (DDD) می‌توانند به سازمان‌ها کمک کنند تا بهتر متوجه شوند هر تیم دقیقاً چه مسئولیتی دارد و چگونه باید با سایر تیم‌ها همکاری کند. یکی از نکاتی که چندین بار روی آن تأکید شد، اهمیت شفاف بودن مرزهای مسئولیت تیم‌ها بود. زمانی که هر تیم وظایف مشخصی داشته باشد، تمرکز بیشتری روی حوزه کاری خود خواهد داشت و در نتیجه سرعت توسعه و کیفیت تصمیم‌گیری نیز افزایش پیدا می‌کند.
یکی از بخش‌ها ، صحبت درباره کاهش بار شناختی تیم‌ها (Cognitive Load) بود. سخنرانان توضیح دادند که اگر یک تیم مجبور باشد هم‌زمان مسئولیت‌های زیادی را بر عهده بگیرد یا در چندین زمینه مختلف فعالیت کند، انرژی زیادی صرف هماهنگی خواهد شد و فرصت کمتری برای نوآوری باقی می‌ماند. به همین دلیل، تقسیم صحیح مسئولیت‌ها باعث می‌شود اعضای تیم بتوانند تمرکز بیشتری روی مسائل اصلی حوزه خود داشته باشند.
بخش دیگری از سخنرانی درباره نقش ابزارهای معماری در ایجاد شفافیت بود Susanne Kaiser .گفت که هدف از استفاده از Wardley Mapping یا DDD صرفاً رسم نمودار نیست، بلکه این ابزارها به تیم‌ها کمک می‌کنند وضعیت فعلی خود را بهتر درک کنند، نقاط ضعف را تشخیص دهند و برای بهبود ساختار سازمان تصمیم‌های منطقی بگیرند. این دیدگاه نشان می‌داد ابزارهای معماری زمانی ارزشمند هستند که باعث بهبود تصمیم‌گیری شوند، نه اینکه فقط مستندات بیشتری تولید کنند.
از دیگر نکات مهم سخنرانی، اهمیت آموزش و انتقال دانش بود James Lewis .در گفت‌وگو اشاره کرد که مشاوران یا معماران نباید فقط مشکلات سازمان را حل کنند، بلکه باید دانش استفاده از این ابزارها را نیز به اعضای تیم منتقل کنند تا پس از پایان پروژه، سازمان بتواند به‌صورت مستقل از آن‌ها استفاده کند Susanne Kaiser .نیز توضیح داد که معمولاً آموزش را با بیان مفاهیم پایه آغاز می‌کند و سپس از مثال‌های ساده استفاده می‌کند تا افراد بتوانند به‌تدریج این روش‌ها را در پروژه‌های واقعی خود به کار بگیرند.
در بخش پایانی، سخنرانان درباره آینده این روش‌ها صحبت کردند Susanne Kaiser بیان کرد که هیچ چارچوبی نباید کاملاً ثابت باشد و این ابزارها نیز باید متناسب با شرایط هر سازمان تغییر کنند. او معتقد بود همان‌طور که سیستم‌های نرم‌افزاری به مرور زمان تکامل پیدا می‌کنند، روش‌های معماری و طراحی سازمان نیز باید قابلیت سازگاری و بهبود مستمر داشته باشند.

عنوان سخنرانی: Building Software Architecture from First Principles

سخنران: Dejan Miličić

لینک ویدیو: https://youtu.be/CkzmPi6h7h8?si=VUH2yaEH8qcBOsdg

این سخنرانی بیشتر از آنکه روی معرفی یک الگوی معماری خاص تمرکز داشته باشد، تلاش می‌کرد توضیح دهد که چگونه می‌توان معماری نرم‌افزار را از اصول پایه و مفاهیم اساسی طراحی کرد Dejan Miličić معتقد بود بسیاری از توسعه‌دهندگان هنگام طراحی سیستم، بیش از حد درگیر انتخاب الگوها و فناوری‌های مختلف می‌شوند، در حالی که ابتدا باید منطق اصلی کسب‌وکار را از معماری و جزئیات فنی جدا کنند.
در بخش ابتدایی ارائه، او چند الگوی مختلف از جمله Transaction Script و  Event Sourcing را با یکدیگر مقایسه کرد. نکته جالب این بود که با وجود تفاوت زیاد این دو الگو، او نشان داد هر دو را می‌توان با چند تابع اصلی مانند decide،  evolve  و init توصیف کرد.
یکی از مهم‌ترین پیام‌های سخنرانی، جداسازی منطق کسب‌وکار از معماری بود Dejan Miličić در سخنرانی می گوید که اگر قوانین و منطق اصلی سیستم در قالب توابع مستقل طراحی شوند، در آینده می‌توان معماری سیستم را بدون تغییر این منطق تغییر داد. برای مثال، اگر یک پروژه در ابتدا با Transaction Script توسعه داده شود و بعداً نیاز به استفاده از Event     Sourcing  داشته باشد، کافی است همان منطق کسب‌وکار در یک ساختار جدید قرار گیرد و نیازی به بازنویسی قوانین اصلی سیستم نخواهد بود.
در ادامه، او درباره Side Effectها صحبت کرد. او توضیح داد که عملیات‌هایی مانند خواندن یا نوشتن در پایگاه داده، ارسال ایمیل یا ارتباط با سرویس‌های دیگر اجتناب‌ناپذیر هستند، اما بهتر است این عملیات به‌صورت مستقیم در منطق اصلی برنامه قرار نگیرند. در عوض باید آن‌ها به شکل مستقل مدل شوند تا کد اصلی ساده‌تر، قابل آزمون‌تر و قابل نگهداری‌تر باشد.
یکی دیگر از بخش‌های مهم سخنرانی، معرفی Event Modeling بود. او می گوید که در این روش، رفتار سیستم با استفاده از سه مفهوم اصلی شامل Command،  Event و State توصیف می‌شود. کاربر ابتدا یک فرمان صادر می‌کند، سپس سیستم تصمیم می‌گیرد که آیا آن فرمان قابل اجرا است یا خیر و در صورت تأیید، یک رویداد ایجاد می‌شود که وضعیت سیستم را تغییر می‌دهد.
همچنین در این ارائه به ارتباط Event Modeling با Domain-Driven Design (DDD) اشاره شد. Dejan گفت که مرزهای موجود در Event Model می‌توانند نقطه شروع مناسبی برای تعیین Bounded Contextها باشند. این موضوع نشان می‌دهد که طراحی معماری و تحلیل دامنه کسب‌وکار ارتباط نزدیکی با یکدیگر دارند و نباید آن‌ها را کاملاً جدا از هم در نظر گرفت.
در پایان، Dejan Miličić سه اصل اساسی را به عنوان پایه‌های معماری نرم‌افزار معرفی کرد. اصل اول، تمرکز بر دامنه کسب‌وکار (Domain-Centricity) بود؛ یعنی معماری باید از نیازهای واقعی کسب‌وکار شروع شود. اصل دوم، استفاده از یک هسته منطقی و خالص (Pure Functional Core) بود که منطق اصلی سیستم را از جزئیات فنی جدا نگه می‌دارد. اصل سوم نیز استفاده از مدل‌سازی معنایی و دقیق برای داده‌ها و تعاملات سیستم بود تا طراحی نرم‌افزار شفاف‌تر و قابل توسعه‌تر شود.