Архитектура

Строим долгосрочные решения и боремся c техническим долгом.

1. Мы заботимся о чистоте API.

  • Мы выставляем сервисы наружу для других команд через API и Портал Разработчиков.
  • Мы следуем Принципам Построения API. Несоответсвующие принципам API должны быть объявлены техническим долгом и поправлены.
  • Сервисы не должны предоставлять клиентскую библиотеку. API и модель данных выражается через REST и JSON. [?].

Практики и ритуалы:

Правило 30%
Каждый инженер может использовать часть своего рабочего времени на исследовательские задачи, на работу над тех. долгом или обучение. Количество процентов примерное и должно определяться техническим лидером совместно с продуктовой командой.

2. Мы используем модулярную архитектуру и избегаем излишнюю связность между продуктами.

  • Модули изолированы и слабо связанны.
  • Модули имеют единую ответственность.
  • Мы можем выкидывать существующий, добавлять новый, или изменять последовательность выполнения модулей безопасно без влияния на соседнюю функциональность.
  • Мы периодически ревьювим важные вопросы архитектуры и технического долга.

Практики и ритуалы:

Архитектурный Комитет

Встреча Enterprise & Solution архитекторов. Проводится по требованию. Лидер - технический директор.

Основные задачи:

  • решение проблем архитектуры
  • место эскалации для архитектурных пробелов или роста технического долга
  • разблокирование задач технического долга
  • консультирование по архитектуре решений
High Cohesion
High Cohesion — это когда класс (или модуль), выполняет четко определенную работу. Low Cohesion - это когда класс выполняет много всего разного. [source]
Внешняя конфигурация
Изменяемая конфигурация должна храниться в окружении.
Оркестрация / Хореография
Микросервисный паттерн для построения последовательности выполнений (САГА). Больше информации тут, или ещё больше тут.


3. Мы разрабатываем только экономически оправданные продукты.

  • Мы избегаем дублирования функциональности систем.
  • Каждая система имеет команду мейнтейнеров, отвечающих за неё.

Практики и ритуалы:

Соотношение доходов и расходов
Для каждого продукта или фичи до начала работ должно быть посчитано соотношение заработанных и потраченных на разработку денег.
KISS
Keep it simple, stupid. Как говорил старина Оккам, «не стоит множить сущее без необходимости». Добавление новых уровней абстракции должно иметь вескую причину. Добавление новых объектов данных или компонентов решения также должно иметь веские основания. Упрощение - это хорошо, и мы это приветствуем. Излишнюю сложность следует признать архитектурным долгом и переработать.
DRY
Don’t Repeat Yorself — Не повторяй сам себя. Иначе говоря, мы не разрабатываем несколько систем, модулей, микросервисов или компонентов с одинаковым предназначением.

Последнее изменение 08.11.2021: Update architecture.md (#39) (fe4691e)