Во оваа статија
Главната идеја
Архитектурата треба да ги олесни реалните промени во системот. Јасните одговорности меѓу модулите се важни уште пред да размислувате за одделни сервиси.
При планирање нов деловен систем, едно од првите технички прашања често е дали да се користат микросервиси. Пред одговорот вреди да се постави друго прашање: кои делови од работата навистина имаат различни правила, одговорности и потреби за промена?
Да замислиме апликација со продажби, магацин и известувања. Таа може да биде една апликација за поставување, а сепак да има јасна внатрешна структура. Ова е практична почетна идеја зад модуларниот монолит.
Границата се гледа во одговорноста
Модулот за продажби ја знае нарачката и нејзините статуси. Модулот за магацин ги знае расположливите количини и резервациите. Модулот за известувања знае како да достави порака. Треба да се договори што секој од нив бара од другите и што враќа како резултат.
На пример, продажбата бара резервација на одредени артикли. Не треба на повеќе места во кодот самостојно да ја менува залихата. Кога правилото за резервација се менува, сакаме да знаеме каде живее и кои сценарија треба повторно да се проверат.
Именувањето папки според модули е корисно, но само по себе не ја создава оваа поделба. Одговорностите треба да се гледаат во интерфејсите, податоците и тестовите.
Одложете ја сложеноста што сè уште не ви треба
Одделните сервиси носат дополнителни прашања за комуникација, поставување и следење. Во текстот Monolith First, Martin Fowler ја објаснува вредноста на почеток со една апликација додека се разјаснуваат границите на доменот. Тој посочува и дека подоцнежното раздвојување не е автоматски лесно: зависностите меѓу деловите и понатаму се важни.
За мал тим, една апликација може да го скрати патот од промена до проверка. Тоа е разумна предност ако главната неизвесност е како треба да работи производот, а не независното опслужување на различни оптоварувања.
Запишете ги одлуките што ќе стареат
Кратка архитектонска белешка може да содржи проблем, избран пристап, разгледани алтернативи и услов за повторно разгледување. На пример: „Известувањата се обработуваат во позадина, но остануваат во истиот проект. Ќе ја преиспитаме поделбата ако нивното оптоварување почне да ја ограничува обработката на нарачки.“
Таквата белешка му помага на следниот програмер да ја разбере причината зад структурата. Спречува и тимот постојано да ја повторува истата дискусија без нови информации.
Запишете кои податоци се во сопственост на секој модул и како се бара промена. Ова е особено корисно кога повеќе луѓе работат паралелно.
Раздвојувајте со конкретна причина
Одделен сервис може да има смисла кога дел од системот има посебен циклус на испорака, различно оптоварување или јасна организациска одговорност. Пред издвојување, проверете како ќе се обработуваат грешки и како ќе се следи едно барање низ двата система.
Изберете мала граница, подгответе тестови за договореното однесување и определете постапка за враќање при проблем. Успехот на промената треба да се гледа во полесната испорака или посигурната работа, според причината поради која сте ја направиле.