Архитектура | Леруа Мерлен Цифровые Технологии

Леруа Мерлен
Цифровые Технологии

Архитектура

Рассказываем, как работаем с архитектурой: заботимся о чистоте API и создаём IT-продукты, которые могут существовать отдельно друг от друга. Всё с примерами и антипримерами.

1. Заботимся о чистоте API.

  • Выставляем сервисы для других команд через API и Портал разработчиков.
  • Следуем Принципам Построения API. Всё, что не соответствует этим принципам, считается техническим долгом.
  • Сервисы не должны предоставлять клиентскую библиотеку. API и модель данных выражается через REST и JSON.

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

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

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

  • Избегаем дублирования функциональности систем.

  • За каждую систему отвечает своя команда мейнтейнеров.

  • Модули изолированы и слабо связанны.

  • У модулей единая ответственность.

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

  • Периодически обсуждаем важные вопросы архитектуры и технического долга.

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

Архитектурный комитет Архитектурный комитет Это встреча Enterprise & Solution архитекторов. Проводится по требованию. Лидер — технический директор.Чем занимается комитет:
- решает проблемы архитектуры
- разблокирует задачи технического долга
- консультирует по архитектуре решений High Cohesion High Cohesion High Cohesion — это когда класс выполняет чётко определённую работу. Low Cohesion — когда класс выполняет много всего разного. Внешняя конфигурация Внешняя конфигурация Изменяемая конфигурация должна храниться в окружении. Оркестрация / Хореография Оркестрация / Хореография Микросервисный паттерн для построения последовательности выполнений — САГА. Больше информации тут.

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

  • Избегаем дублирования функциональности систем.
  • За каждую систему отвечает своя команда мейнтейнеров.

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

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