Сваког дана, сваког тренутка током наше инжењерске каријере, сусрећемо се са много различитих проблема различите сложености и ситуација у којима морамо да донесемо одлуку или да је одложимо због недостатка података. Кад год градимо нове услуге, градимо инфраструктуру или чак формирамо развојне процесе, додирујемо огроман свет различитих изазова.
Изазовно је, а можда чак и немогуће, навести све проблеме. Наићи ћете на неке од ових проблема само ако радите у одређеној ниши. С друге стране, постоји много тога које сви морамо да разумемо како да решимо, јер су они кључни за изградњу ИТ система. Са великом вероватноћом ћете их срести у свим пројектима.
У овом чланку ћу поделити своја искуства са неким проблемима на које сам наишао приликом креирања софтверских програма.
Ако погледамо Википедију, наћи ћемо следећу дефиницију
У аспектно оријентисаном развоју софтвера, међусекторска питања су аспекти програма који утичу на неколико модула, без могућности да буду инкапсулирани у било који од њих. Ови проблеми се често не могу јасно раздвојити од остатка система иу дизајну и у имплементацији, и могу довести до распршивања (дуплицирање кода), запетљавања (значајне зависности између система) или обоје.
У великој мери описује шта је то, али желим да га мало проширим и поједноставим:
Међусекторска брига је концепт или компонента система/организације која утиче (или 'пресече') многе друге делове.
Најбољи примери таквих брига су архитектура система, евидентирање, безбедност, управљање трансакцијама, телеметрија, дизајн базе података и постоје многи други. Касније ћемо у овом чланку елаборирати многе од њих.
На нивоу кода, свеобухватни проблеми се често имплементирају коришћењем техника као што је Аспецт-Ориентед Программинг (АОП) , где су ови проблеми модулисани у засебне компоненте које се могу применити у целој апликацији. Ово држи пословну логику изолованом од ових брига, чинећи код читљивијим и одржавајућим.
Постоји много могућих начина како да класификујете аспекте тако што ћете их сегментирати различитим својствима као што су обим, величина, функционалност, важност, циљ и други, али у овом чланку ћу користити једноставну класификацију опсега. Под овим мислим на то где је усмерен овај специфични аспект, било да се ради о целој организацији, одређеном систему или специфичном елементу тог система.
Дакле, поделићу аспекте на Макро и Микро .
Под макро аспектом мислим углавном на разматрања која следимо за цео систем, као што су одабрана архитектура система и његов дизајн (монолит, микросервис, сервисно оријентисана архитектура), технолошки стек, организациона структура, итд. Макро аспекти су углавном повезани са стратешким и високим нивоом. одлуке.
У међувремену, микро аспект је много ближи нивоу кода и развоју. На пример, који оквир се користи за интеракцију са базом података, структуру пројекта фасцикли и класа, или чак специфичне обрасце дизајна објеката.
Иако ова класификација није идеална, она помаже да се структурира разумевање могућих проблема и важности и утицаја решења која примењујемо на њих.
У овом чланку, мој примарни фокус ће бити на макро аспектима.
Када сам тек почео да учим о архитектури софтвера, прочитао сам много занимљивих чланака о Конвејевом закону и његовом утицају на организациону структуру. Посебно овај . Дакле, овај закон то каже
Свака организација која дизајнира систем (широко дефинисан) ће произвести дизајн чија је структура копија комуникацијске структуре организације.
Увек сам веровао да је овај концепт заиста веома универзалан и да представља Златно правило.
Затим сам почео да учим приступ дизајна вођеног доменом (ДДД) Ерица Еванса за моделирање система. Ерик Еванс наглашава важност идентификације ограниченог контекста. Овај концепт укључује поделу комплексног модела домена на мање делове којима је лакше управљати, сваки са сопственим ограниченим скупом знања. Овај приступ помаже у ефикасној тимској комуникацији, јер смањује потребу за опсежним познавањем читавог домена и минимизира промену контекста, чинећи тако разговоре ефикаснијим. Промена контекста је најгора ствар и која захтева највише ресурса. Чак се и рачунари боре са тим. Иако је мало вероватно да ће се постићи потпуно одсуство промене контекста, мислим да је то оно чему треба да тежимо.
Враћајући се на Конвејев закон, нашао сам неколико проблема у вези са њим.
Прво питање са којим сам се сусрео са Конвејевим законом, који сугерише да дизајн система одражава организациону структуру, јесте потенцијал за формирање сложених и свеобухватних ограничених контекста. Ова сложеност настаје када организациона структура није усклађена са границама домена, што доводи до ограничених контекста који су у великој мери међусобно зависни и оптерећени информацијама. То доводи до честог мењања контекста за развојни тим.
Друго питање је то што терминологија организације цури на ниво кода. Када се организационе структуре промене, то захтева модификације базе кода, трошећи вредне ресурсе.
Стога, праћење Инверзног Цонваи маневра помаже у изградњи система и организације који подстичу жељену архитектуру софтвера. Међутим, вреди напоменути да овај приступ неће добро функционисати у већ формираној архитектури и структурама јер су промене у овој фази дуготрајне, али је изузетно ефикасан у стартапима јер брзо уводе било какве промене.
Овај образац или „анти-паттерн“ покреће изградњу система без икакве архитектуре. Нема правила, нема граница и нема стратегије како да контролишете неизбежно растућу сложеност. Сложеност је најстрашнији непријатељ на путу изградње софтверских система.
Да бисмо избегли конструисање таквог типа система, морамо да се придржавамо специфичних правила и ограничења.
Постоји безброј дефиниција за софтверску архитектуру. Многи од њих ми се свиђају јер покривају различите аспекте тога. Међутим, да бисмо могли да размишљамо о архитектури, морамо природно да формирамо неке од њих у свом уму. И вреди напоменути да се ова дефиниција може развијати. Дакле, бар за сада, имам следећи опис за себе.
Архитектура софтвера се односи на одлуке и изборе које доносите сваки дан и који утичу на изграђен систем.
Да бисте донели одлуке које морате да имате у својој „торби“ принципе и обрасце за решавање насталих проблема, такође је од суштинске важности да кажете да је разумевање захтева кључно за изградњу онога што је потребно предузећу. Међутим, понекад захтеви нису транспарентни или чак нису дефинисани, у овом случају је боље сачекати да добијете додатна појашњења или се ослонити на своје искуство и веровати својој интуицији. Али у сваком случају, не можете правилно доносити одлуке ако немате принципе и обрасце на које се можете ослонити. Ту долазим до дефиниције стила софтверске архитектуре.
Стил софтверске архитектуре је скуп принципа и образаца који одређују како се прави софтвер.
Постоји много различитих архитектонских стилова фокусираних на различите стране планиране архитектуре, а примена више њих одједном је нормална ситуација.
На пример, као што су:
Монолитна архитектура
Дизајн вођен доменом
Компонентни
Микроуслуге
Цеви и филтери
Догађај-дривен
Мицрокернел
Сервисно оријентисан
и тако даље…
Наравно, они имају своје предности и мане, али најважнија ствар коју сам научио је да се архитектура постепено развија зависно од стварних проблема. Почевши од монолитне архитектуре је одличан избор за смањење оперативних сложености, врло је вероватно да ће ова архитектура одговарати вашим потребама чак и након достизања фазе прилагођавања тржишту производа (ПМИ) изградње производа. У великој мери, можете размислити о преласку на приступ вођен догађајима и микроуслуге за постизање независног привођења, хетерогеног окружења технолошког стека и мање повезане архитектуре (и мање транспарентне у међувремену због природе приступа вођених догађајима и пуб-суб приступа ако ови се усвајају). Једноставност и ефикасност су блиске и имају велики утицај једна на другу. Обично компликоване архитектуре утичу на брзину развоја нових карактеристика, подржавајући и одржавајући постојеће, и изазивајући природну еволуцију система.
Међутим, сложени системи често захтевају сложену и свеобухватну архитектуру, што је неизбежно.
Искрено, ово је веома широка тема и постоји много сјајних идеја о томе како структурирати и изградити системе за природну еволуцију. На основу свог искуства, разрадио сам следећи приступ:
Такође је од виталног значаја да разумете бројеве и метрике као што су ДАУ (Дневни активни корисници), МАУ (Месечно активни корисници), РПЦ (Захтев у секунди) и ТПЦ (Трансакција у секунди) јер би вам то могло помоћи да донесете одлуке јер архитектура за 100 активних корисника и 100 милиона активних корисника се разликују.
Као завршну напомену, рекао бих да архитектура има значајан утицај на успех производа. У скалирању је потребна лоше дизајнирана архитектура за производе, што врло вероватно доводи до неуспеха јер купци неће чекати док скалирате систем, већ ће изабрати конкурента, тако да морамо бити испред потенцијалног скалирања. Иако признајем да понекад то не може бити леан приступ, идеја је да имамо скалабилан, али не већ скалиран систем. С друге стране, поседовање веома компликованог и већ скалираног система без купаца или планова да добијете многе од њих ће вас коштати новца за ваше пословање узалуд.
Избор технолошког стека је такође одлука на макро нивоу јер утиче на запошљавање, перспективе природне еволуције система, скалабилност и перформансе система.
Ово је листа основних разматрања за одабир технолошке групе:
Како постојање више технолошких група може утицати на раст пословања?
Из једне перспективе, увођење још једне групе могло би повећати ваше запошљавање, али с друге стране, то доноси додатне трошкове одржавања јер морате подржати оба стека. Дакле, као што сам раније рекао, по мом мишљењу, само додатна потреба треба да буде аргумент за укључивање више технолошких стекова.
Али шта је са принципом одабира најбољег алата за одређени проблем?
Понекад немате другог избора осим да донесете нове алате за решавање одређеног проблема на основу истих претходно наведених разматрања, у таквим случајевима има смисла изабрати најбоље решење.
Стварање система без високе повезаности са специфичном технологијом може бити изазов. Ипак, корисно је тежити стању у којем систем није чврсто повезан са технологијом и неће умрети ако сутра одређени оквир или алатка постану рањиви или чак застарели.
Још једно важно питање односи се на зависности од отвореног кода и власничког софтвера. Власнички софтвер вам даје мању флексибилност и могућност прилагођавања. Ипак, најопаснији фактор је закључавање добављача, где постајете зависни од производа, цена, услова и мапе пута добављача. Ово може бити ризично ако продавац промени правац, повећа цене или прекине производ. Софтвер отвореног кода смањује овај ризик, јер га не контролише један ентитет. Елиминисање једне тачке квара на свим нивоима је кључ за изградњу поузданих система за раст.
Појединачна тачка квара (СПОФ) се односи на било који део система који ће, ако откаже, узроковати да цео систем престане да функционише. Елиминисање СПОФ-ова на свим нивоима је кључно за сваки систем који захтева високу доступност. Све, укључујући знање, особље, системске компоненте, цлоуд провајдере и интернет каблове, може да пропадне.
Постоји неколико основних техника које можемо применити да елиминишемо појединачне тачке квара:
У овом чланку смо покрили неколико кључних макро аспеката и како се можемо носити са њиховом сложеношћу.
Хвала на читању! Видимо се следећи пут!