معماری نرم افزار تکاملی

عنوان سخنرانی: Building Evolutionary Architectures - Rebecca Parsons - XConf EU 2018

سخنران: Rebecca Parsons

ویدئو: با همین "عنوان سخنرانی" در یوتوب تماشا کنید.

در این مطلب قصد دارم ویدئوی معرفی شده را تحلیل کنم و برداشت خود را از مفاهیم مطرح شده در آن با شما به اشتراک بگذارم. موضوع اصلی این سخنرانی، مفهوم معماری تکاملی است؛ رویکردی که تلاش می‌کند معماری نرم افزار را با واقعیت پرشتاب تغییرات در محیط کسب و کار و فناوری سازگار کند.

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

در این سخنرانی، معماری نه به عنوان یک طرح ثابت، بلکه به عنوان فرآیندی پویا در نظر گرفته می شود که باید بتواند همراه با سیستم تکامل پیدا کند. این نگاه ریشه در مفاهیم محاسبات تکاملی دارد، جایی که سیستم ها بر اساس مجموعه ای از معیارهای سنجش یا همان Fitness Function ها به تدریج به سمت وضعیت مطلوب حرکت می کنند. در معماری نرم افزار نیز این مفهوم به این معناست که به جای تعیین شکل نهایی سیستم، باید مجموعه ای از ویژگی های مطلوب برای آن تعریف شود؛ مانند کارایی، امنیت، قابلیت تغییرپذیری یا مقیاس پذیری. سپس تصمیم های معماری و فناوری باید در جهت بهبود این ویژگی ها هدایت شوند.

یکی از نکات مهم در این رویکرد، پذیرش مفهوم trade-off در معماری است. در بسیاری از موارد نمی توان همه ویژگی های معماری را به صورت همزمان بهینه کرد. برای مثال افزایش سطح امنیت معمولا هزینه هایی در کارایی سیستم ایجاد می کند. بنابراین معماری در عمل مجموعه ای از مصالحه ها میان اهداف مختلف است. در معماری تکاملی تلاش می شود این مصالحه ها به صورت آگاهانه و بر اساس معیارهای مشخص انجام شوند.

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

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

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

همچنین به نقش ارتباطات سازمانی در شکل گیری معماری باید توجه کرد. بر اساس قانون Conway، ساختار سیستم های نرم افزاری معمولا بازتابی از ساختار ارتباطی سازمان ها هستند. اگر تیم های توسعه ارتباط ضعیفی با یکدیگر داشته باشند، این شکاف در معماری سیستم نیز ظاهر می شود. بنابراین معماری تنها یک مسئله فنی نیست و تا حد زیادی تحت تاثیر ساختار سازمانی و الگوهای ارتباطی تیم ها قرار دارد.

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

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

در معماری مبتنی بر سرویس نیز تمایزی میان ارکستراسیون و کوریوگرافی مطرح می شود. در ارکستراسیون یک جزء مرکزی جریان تعامل میان سرویس ها را کنترل می کند. در مقابل، در کوریوگرافی هر سرویس بر اساس قواعد مشخص به رویدادها واکنش نشان می دهد. این رویکرد کنترل متمرکز را کاهش می دهد و در نتیجه امکان تغییر و تکامل مستقل اجزای سیستم را افزایش می دهد، هرچند در مقابل پیچیدگی های جدیدی در مدیریت خطا ایجاد می کند.

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

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

منابع

• Team Topologies: Organizing Business and Technology Teams for Fast Flow Book by Manuel Pais and Matthew Skelton

• Neal Ford. Principles of Evolutionary Architecture. Conference Talk.

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

#معماری_نرم_افزار_بهشتی