Статьи серии:

Architectural Decision Records (ADR)
Architectural Decision Records (ADR). Y-Statements

В предыдущей статье я описывал ADR и упустил подробности про "Y-Statements". Приведу в этой заметке немного подробностей.

Напомню, что Architectural Decision Records (ADR) отвечает на вопрос "почему". Почему было принято то или иное решение. Почему используется та или иная технология, подход или паттерн.

Y-Statements

Под "Y-statements" подразумевается "(WH)Y-statements".

"Y-statements" - это шаблон, который может быть использован для создания ADR. Этот шаблон помогает ответить на вопрос "почему" так, чтобы было понятно как, зачем и когда принималось решение.

Y-Statements включает в себя следующие части/разделы:

1. context (контекст) - то, на что будет распространяться эффект. Пользовательские истории, функциональные требования или компонент.
2. facing (причина) - нефункциональные требования, SLA, проблема.
3. we decided for (принято) - результат принятия решения. аргументы и ключевые моменты.
4. neglected (отклонено) - альтернативы, которые не были приняты.
5. to achieve (достигнуто) - выгода от принятого решения, полное или частичное удовлетворение требований.
6. accepting that (нужно учесть) - недостатки принятого решения. Влияние на другие компоненты, характеристики или требования. Затраты.

Пример для этого шаблона будет выглядеть так:

1. В сервисе обратной связи случалась следующая проблема.
2. Деградация производительности базы данных, так как мы не умеем готовить PostgreSQL.
3. Мы приняли решение перейти на MongoDB, потому-что научить разработчиков нормально писать код мы не можем.
4. Мы ходили на конференцию и там сказали, что MongoDB рулит. Альтернативы в виде ArangoDB и Cassandra не прошли из-за отсутствия опыта работы с ними у разработчиков и devops. Marklogic слишком дорогой.
5. С MongoDB приложение сможет выдерживать большие нагрузки и мы продолжим развиваться. А еще не нужно будет искать дорогих программистов.
6. Затраты на миграцию будут значительными, но мы компенсируем это нанимая дешёвых говнокодеров. Нужно мигрировать быстро, пока последний нормальный разработчик не уволился и он может это сделать.

⚠ Данный пример сделан только ради шутки и может не отражать значимость, надежность и удобство той или иной технологии. Автор не ставил целью задеть чувства ребят работающих с MongoDB. Надеюсь, чувства говнокодеров тоже не задеты.

Перечисленные пункты обычно представляют так:

Есть вот такая таблица соответствия между Y-statements и другими популярными шаблонами. Не уверен, что оно мне надо, но пусть будет тут.

Интересное

Y-Statements
Architectural Decisions — The Making Of <- картинки взяты тут