Architecture Decision RecordПроцес за записи на архитектурни решения в AWS
Записът на архитектурно решение (ADR) е документ, който описва избор, направен от екипа относно съществен аспект от софтуерната архитектура, която планира да изгради. Всеки ADR описва архитектурното решение, неговия контекст и последиците от него. ADR имат състояния и следователно следват жизнен цикъл. За пример за ADR вижте приложението.
Процесът за ADR води до колекция от записи на архитектурни решения. Тази колекция образува дневника на решенията. Дневникът на решенията предоставя контекста на проекта, както и подробна информация за реализацията и проектирането. Членовете на проекта преглеждат заглавията на всеки ADR, за да добият общ поглед върху контекста на проекта. Те четат ADR, за да се задълбочат в реализациите на проекта и изборите при проектирането.
Когато екипът приеме даден ADR, той става неизменим. Ако нови прозрения налагат различно решение, екипът предлага нов ADR. Когато екипът приеме новия ADR, той измества предишния ADR.
Обхват на процеса за ADR
Членовете на проекта трябва да създават ADR за всяко архитектурно значимо решение, което засяга софтуерния проект или продукт, включително следното (Richards and Ford 2020):
Структура (например модели като микроуслуги)
Нефункционални изисквания (сигурност, висока наличност и устойчивост на грешки)
Зависимости (свързаност на компонентите)
Интерфейси (API и публикувани договори)
Техники за изграждане (библиотеки, рамки, инструменти и процеси)
Функционалните и нефункционалните изисквания са най-често срещаните входни данни за процеса за ADR.
Съдържание на ADR
Когато екипът установи нужда от ADR, член на екипа започва да пише ADR въз основа на шаблон за целия проект. (Вижте организацията ADR в GitHub за примерни шаблони.) Шаблонът улеснява създаването на ADR и гарантира, че ADR обхваща цялата съответна информация. Като минимум всеки ADR трябва да определя контекста на решението, самото решение и последиците от решението за проекта и неговите резултати. (За примери на тези раздели вижте приложението.) Един от най-силните аспекти на структурата на ADR е, че тя се фокусира върху причината за решението, а не върху начина, по който екипът го е реализирал. Разбирането защо екипът е взел решението улеснява останалите членове на екипа да го възприемат и предотвратява други архитекти, които не са участвали в процеса на вземане на решения, да го отменят в бъдеще.
Процес на приемане на ADR
Всеки член на екипа може да създаде ADR, но екипът трябва да установи определение за собственост върху ADR. Всеки автор, който е собственик на ADR, трябва активно да поддържа и да съобщава съдържанието на ADR. За да изясни тази собственост, настоящото ръководство нарича авторите на ADR собственици на ADR в следващите раздели. Останалите членове на екипа винаги могат да допринасят към ADR. Ако съдържанието на ADR се промени, преди екипът да го приеме, собственикът трябва да одобри тези промени.
След като екипът определи архитектурно решение и неговия собственик, собственикът на ADR предоставя ADR в състояние Предложен в началото на процеса. ADR в състояние „Предложен“ са готови за преглед.
След това собственикът на ADR инициира процеса на преглед на ADR. Целта на процеса на преглед на ADR е да реши дали екипът приема ADR, преценява, че се нуждае от преработка, или отхвърля ADR. Проектният екип, включително собственикът, прави прегледа на ADR. Срещата за преглед трябва да започне със специално отделено време за четене на ADR. В повечето случаи 10 до 15 минути са достатъчни. През това време всеки член на екипа чете документа и добавя коментари и въпроси, за да отбележи неясните теми. След фазата на преглед собственикът на ADR прочита на глас и обсъжда с екипа всеки коментар.
Ако екипът намери действия за подобряване на ADR, състоянието на ADR остава Предложен. Собственикът на ADR формулира действията и, в сътрудничество с екипа, назначава изпълнител на всяко действие. Всеки член на екипа може да допринася и да приключва действията. Отговорност на собственика на ADR е да насрочи отново процеса на преглед.
Екипът може също да реши да отхвърли ADR. В този случай собственикът на ADR добавя причина за отхвърлянето, за да се предотвратят бъдещи дискусии по същата тема. Собственикът променя състоянието на ADR на Отхвърлен.
Ако екипът одобри ADR, собственикът добавя времеви печат, версия и списък със заинтересованите страни. След това собственикът обновява състоянието на Приет.
ADR и дневникът на решенията, който те създават, представляват решения, взети от екипа, и предоставят история на всички решения. Екипът използва ADR като справка по време на прегледите на кода и на архитектурата, където е възможно. В допълнение към извършването на прегледи на код, задачи по проектиране и задачи по реализация, членовете на екипа трябва да се консултират с ADR за стратегически решения за продукта.
Като добра практика всяка промяна в софтуера трябва да премине през партньорски прегледи и да изисква поне едно одобрение. По време на прегледа на кода рецензентът може да установи промени, които нарушават един или повече ADR. В този случай рецензентът моли автора на промяната в кода да актуализира кода и споделя връзка към ADR. Когато авторът актуализира кода, той се одобрява от партньорските рецензенти и се слива в основната кодова база.
Процес на преглед на ADR
Екипът трябва да третира ADR като неизменими документи, след като ги е приел или отхвърлил. Промените в съществуващ ADR изискват създаване на нов ADR, установяване на процес на преглед за новия ADR и одобряване на ADR. Ако екипът одобри новия ADR, собственикът трябва да промени състоянието на стария ADR на Заменен.