مروری بر کنفرانس های مرتبط با معماری نرم افزار

عنوان: Monolith Decomposition Patterns

سخنران: Sam Newman

لینک

در این سخنرانی Sam Newman چالش هایی در مورد حرکت از معماری Monolith به سمت معماری Microservice را مورد بحث قرار می دهد. Newman اصلی ترین انگیزه شرکت ها برای رفتن به سمت معماری Microservice را ویژگی Independeent deployability معرفی می کند که به تیم‌ها اجازه می‌دهند تا به طور مستقل کار کنند و تغییرات هدفمند ایجاد کنند. همچنین ازمزایای معماری Modular Monolith سخن گفته می شود که وقتی مرز ماژول ها به خوبی تعریف شده و پیشنهاد می‌کند که برای برخی شرکت‌ها ممکن است آنها مناسب‌تر از معماری Microservice باشند. این کنفرانس یک معماری را برای استارت‌آپ‌ها معرفی می‌کند،Modular Monolith با جداسازی داده‌ها برای هر ماژول، برای مهاجرت احتمالی آینده به معماری Microservice زیرا یکی از مشکلات اصلی که در زمان مهاجرت از Monolith به Microservice با آن مواجه می شویم، حجیم بودن Database نرم افزار است.

برای حرکت به سمت معماری Microservice، درک اینکه چرا می خواهیم مهاجرت کنیم و انجام طراحی Domain-Driven برای شناسایی مرزهای سرویس ها را توصیه می‌ شود، همچنین Newman تاکید می کند که این مهاجرت نباید به صورت ناگهانی و همه جانبه باشد بلکه به صورت افزایشی شروع به پیداکردن سرویس ها می کنیم.

الگو هایی که برای مهاجرت از معماری Monolith به Microservice در این کنفرانس معرفی می شوند:

الگو اول: Strangler fig application pattern

ایده این الگو از یک گیاه با نام strangler fig گرفته شده که چگونه در شرایط جوی سخت رشد می کند. ایده این است که ما یک نرم افزار با معماری Monolith داریم که نیازمندی های مختلف ما را برطرف می کند حال سعی می کنیم یک نرم افزار با معماری Microservice حول آن ایجاد کنیم، همچنین در مورد اهمیت اینکه ابتدا چه نیازمندی هایی را برای مهاجرت انتخاب کنیم بحث می شود.

الگو دوم: Branch by abstraction

این روش به این صورت است که می خواهیم فضایی را در سیستم monolith موجود خود ایجاد کنیم، که در آن بتوانیم دو پیاده سازی از یک عملکرد یکسان را در کنار هم داشته باشیم.

عنوان: Five Things Every Developer Should Know about Software Architecture

سخنران: Simon Brown

لینک

- Software architecture isn't about big design upfront

در این سخنرانی Simon Brown می خواهد تفکر اشتباه در مورد معماری نرم افزار را اصلاح کند، اکثر توسعه دهندگان وقتی در مورد معماری نرم افزار فکر می کنند آن را مترادف با big picture upfront تصور می کنند در صورتی که این دو متفاوتند. در واقع می گوید که مهندسی نرم افزار و معماری نرم افزار دو مبحث مختلف اند.

- Every software team needs to consider software architecture

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

- The software architecture role is about coding, coaching & collaboration

همچنین در این سخنرانی این دیدگاه نسبت به معماران نرم افزار که افرادی مستبدند را منسوخ شده معرفی می کند، در واقع سعی می کند رویکرد shared or pair architecting را معرفی کند.

- You don't need to use UML

سخنران(Simon Brown) در مورد اینکه استفاده از UML در معماری نرم افزار ضرورت نیست، اگرچه به عنوان یک زبان مشترک برای نمودارسازی و تجسم عمل می کند. روش‌های جایگزین مانند whiteboarding و مدل C4 برای تجسم معماری بیان می‌شوند.

- A good software architecture enables agility

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

عنوان: Why Architectural Work Comes Before Coding

سخنرانان: Simon Brown, Stefan Tilkov

لینک

در این کنفرانس تأکید می شود که معماری نرم افزار برای همه توسعه دهندگان، نه فقط برای کسانی که عنوان معمار نرم افزار دارند، بسیار مهم است. این به این دلیل است که تصمیمات معماری بر کل تیم و پروژه تأثیر می گذارد، به این معنا که نقش معمار نرم افزار نباید دیکتاتوری باشد، درواقع معماری نرم افزار مجموعه ای از وظایف و مسئولیت هاست که باید به طور مشترک بین تیم تقسیم شود.

تیم ها باید به اندازه کافی طراحی اولیه انجام دهند به این معنا که نه بدون طراحی باشیم و نه طراحی بیش از حد بزرگ قبل از پیاده سازی داشته باشیم. توصیف درست معماری به تیم‌ها اجازه می‌دهد تا tradeoff ها را بررسی کنند.

چابکی یا agility باعث شده برخی از تیم ها از معماری غافل شوند، اما چابکی و معماری خوب در واقع مکمل یکدیگر هستند.

ابزارهای همکاری remote ذاتاً ساختار معماری زیادی ارائه نمی دهند. ممکن است مشکلاتی در مورد توسعه ابزارهایی وجود داشته باشد که رسمیت را با انعطاف پذیری متعادل می کند.

به طور کلی، این کنفرانس سخنرانان تفکراتشان را در مورد نقش و شیوه های معماری نرم افزار مدرن توصیف می کنند.نظر Brown بر احیای معماری به روشی مناسب برای توسعه‌دهندگان متمرکز است که بهترین‌ روش ها را از شیوه‌های سنتی انتخاب می کند بدون اینکه زیاده‌روی کند، در حالی که انعطاف‌پذیری و agility را در بر می‌گیرد.

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