Перейти к содержанию
В рабочем режимеПоследний релиз · 4 часа назадВ работе · 6 проектовОтвет · в течение 4 часовТолько сеньоры-партнёрыMMXXVIВ рабочем режимеПоследний релиз · 4 часа назадВ работе · 6 проектовОтвет · в течение 4 часовТолько сеньоры-партнёрыMMXXVIВ рабочем режимеПоследний релиз · 4 часа назадВ работе · 6 проектовОтвет · в течение 4 часовТолько сеньоры-партнёрыMMXXVI
SmartyDevs
Модернизация · 03

Декомпозиция, сделанная честно.

Монолит в микросервисы, микросервисы обратно в модульный монолит, или domain-driven декомпозиция, уважающая размер вашей команды. Дадим ответ, который подходит — а не модный.

§ 01The problem

Какую проблему решаем

Микросервисы стали default-выбором для компаний без operational-зрелости, чтобы их вести. И наоборот, некоторые команды застряли в монолитах, которые реально стоит декомпозировать. Оцениваем честно и выполняем точно — включая возможность сказать, что правильный ответ — консолидация, а не split.

§ 02Capabilities

Что делаем

  • 01Честная оценка того, оправдана ли декомпозиция
  • 02Domain-driven декомпозиция с bounded contexts
  • 03Извлечение сервисов через strangler-fig pattern
  • 04Anti-corruption layers на границах сервисов
  • 05Владение данными и паттерны inter-service consistency
  • 06Inter-service контракты (REST, gRPC, события)
  • 07Service mesh там, где он реально решает проблемы
  • 08Дизайн модульного монолита как credible-альтернативы
  • 09Recomposition: микросервисы обратно в монолит там, где уместно
§ 03Deliverables

Что получаете

  • Письменное архитектурное решение с trade-off'ами
  • Фазированный план декомпозиции с риском на фазу
  • Реализация первых извлечений сервисов
  • Операционная модель новой архитектуры
§ 04Stack

Паттерны, которые используем

Domain-driven design
Bounded contexts
Strangler-fig извлечение
Модульный монолит
Outbox-паттерн
Saga / choreography
Anti-corruption layers
Service mesh (выборочно)
§ 05Ideal for

Подходит

  • Компаниям, рассматривающим переход на микросервисы
  • Командам, чья микросервисная разрастёт стала обузой
  • Инженерным лидерам, унаследовавшим систему с неясными границами
  • Фаундерам, решающим, какую архитектурную форму должны принять следующие 18 месяцев
§ 06Process

Как идёт проект

  1. 01

    Оценка

    Честная ревизия, оправдана ли декомпозиция. Часто ответ — «сначала модульный монолит, сервисы позже».

  2. 02

    Дизайн

    Bounded contexts, границы сервисов, владение данными — записаны с trade-off'ами.

  3. 03

    Извлечение

    Первые сервисы извлечены через strangler-fig с параллельной работой.

  4. 04

    Эксплуатация

    Операционная модель, наблюдаемость и runbook'и новой архитектуры.

§ 07Engagement

Как сотрудничать

01

Decomposition Assessment

2 — 4 недели

Честная оценка того, делать ли декомпозицию, с письменным решением.

02

Decomposition Programme

6 — 18 месяцев

Оценка плюс фазированное выполнение с нашей командой.

03

Recomposition

3 — 9 месяцев

Для команд, чьи микросервисы разрастлись за пределы полезности — консолидация делается безопасно.

§ 08Common questions

Frequently asked.

01Не порекомендуете ли микросервисы просто потому что модно?

Часто рекомендуем против. Честный ответ для большинства команд до 50 инженеров — хорошо спроектированный модульный монолит. Скажем правду, даже когда она немодная.

02Можете ли помочь консолидировать микросервисы обратно в монолит?

Да — это одна из самых высоко-leverage работ, которую мы делаем. Service proliferation реальна, и реверс часто правильный.

Есть задача, которую стоит решить как следует?

Напишите, какой результат нужен. Мы честно скажем, во что это обойдётся — письменно, в течение недели.

Начать разговор