Недавно я побывал на архитектурном митапе Т1 в Москве.
По стечению обстоятельств в этот раз я был гостем, а не ведущим, но для восприятия митапа это скорее плюс. Удалось спокойно послушать, осмыслить, пообщаться в кулуарах и собрать общую картину обсуждений.

Простые системы против «стандартов ради стандартов»

Одна из ключевых тем митапа — простые системы и разумная достаточность.
Мы много говорили о том, что во множестве реальных кейсов можно и нужно выбирать более простые решения, а не тащить в маленький проект весь «энтерпрайз‑зоопарк» только потому, что «так сейчас принято».

Хороший пример — использование PostgreSQL вместо связки Redis + Kafka + ещё одной БД для небольших систем.
Для типовой небольшой нагрузки PostgreSQL способен одновременно выполнять роли:

  • Основной базы данных.
  • Кэша.
  • Простого брокера сообщений.

В итоге в IT‑инфраструктуре получается меньше:

  • Точек отказа.
  • Независимых узлов.
  • Сложных связей между сервисами.

Для небольших систем это даёт понятный выигрыш: всё работает предсказуемо, инфраструктура проще, а необходимость менять провайдера или усложнять стек может вообще не наступить довольно долго.

Как DDD помогает эволюционировать архитектуру

Ещё один важный аспект обсуждения — то, как принципы Domain-Driven Design помогают со временем эволюционировать архитектуру.

Если с самого начала аккуратно выделять домены, bounded contexts и явные границы между ними, то переход с «простого» решения на более тяжёлый, специализированный стек становится легче:

  • Понятнее, где именно растёт нагрузка.
  • Проще выделить участок системы, который пора «разнести» на отдельные сервисы.
  • Легче заменить один технологический компонент другим (БД, брокер, кэш), не ломая всё приложение.

То есть DDD здесь работает как страховка: начинаем с проще‑не‑бывает, но закладываем структуру, которая позволит безболезненно дорастать до более сложных решений.

Путешествия между стеками и заимствование идей

Была ещё одна интересная дискуссия — про то, как разработчики путешествуют между стеками и языками.
Иногда опыт из одного стека приносит в другой сильные решения, а иногда заимствование идей и подходов только мешает.

Примеры, о которых говорили:

  • Удачное заимствование: перенос концепций из функционального программирования в объектно‑ориентированный код — больше внимания к неизменяемости, чистым функциям, декларативному стилю.
  • Неудачное заимствование: попытка построить «микросервисы в миниатюре» внутри монолита или перенести паттерны из совсем другого домена без оглядки на реальную предметную область.

Во время обсуждения я поймал себя на мысли, что сам этим страдаю не только в программировании, но и при анализе предметной области. Иногда автоматически применяю знакомые паттерны, не задав лишний раз вопрос «А здесь это действительно уместно?».

Docs as Code и интеграция с AI‑агентами

Отдельный блок был посвящён практике Docs as Code.
Это подход, где документация живёт рядом с кодом, в репозиториях, версионируется, ревьюится и деплоится так же, как и сама система.

Особый акцент сделали на интеграции документации с AI‑агентами:

  • Документация становится «топливом» для ИИ‑ассистентов.
  • Появляется возможность строить поверх неё умные помощники для разработчиков, аналитиков и архитекторов.
  • Качество и структура документации напрямую влияют на то, насколько полезны эти ассистенты.

Сейчас видно, что направление Docs as Code + AI набирает популярность, и я тоже планирую более активно его потестировать в своих проектах.

Infrastructure as Code и Architecture as Code

Логичным продолжением обсуждения стало движение от Docs as Code к Infrastructure as Code и Architecture as Code, интересно было послушатиь мнение коллег и то что все так или иначы начинают внедрять подходы в работу.

  • Infrastructure as Code (IaC) уже стала де‑факто стандартом: инфраструктура описывается декларативно, хранится в репозиториях, проходит код‑ревью.
  • Architecture as Code (AaC) — следующий шаг: архитектурные решения, связи между компонентами, ограничения и допущения описываются в формализованной форме, пригодной для автоматизированной проверки и анализа.

Кстати, недавно у моих друзей из ИнфоТеКС была статья о том, как они применяют Architecture As Code на практике и какие инструменты для этого используют:
Architecture As Code в Инфотекс на Habr.

Вместо итогов

Для меня главный инсайт митапа:

  • Простые решения часто закрывают реальные потребности лучше, чем «правильный по стандартам, но избыточный» стек.
  • DDD помогает оставаться гибким и не загонять систему в угол.
  • Путешествовать между стеками полезно, но только если осознанно переносить идеи.
  • Docs as Code и Architecture as Code в связке с AI‑агентами — это уже не футуризм, а практический вектор развития архитектурных практик.

Планирую вернуться к этим темам в следующих постах и разобрать отдельные примеры подробнее.