Привет, Хабр! Меня зовут Виктор Овчинников, я руковожу продуктовым направлением «Интеграционная платформа» в «Диасофт». Той самой Digital Q.Integration, которую вы имеете полное право не покупать.

Под каждой моей статьей появляется один и тот же комментарий. Слова разные, смысл один: зачем вообще нужна интеграционная платформа, если есть Kafka, брокер сообщений? Один сервис положил сообщение, второй забрал. В чем, собственно, проблема?

Раньше я отвечал в комментариях каждому, потом понял, что проще ответить сразу всем. И заодно признать неприятное: в изрядной части случаев этот комментарий справедлив. Хорошая новость в том, что за годы разговоров с коллегами из других компаний у меня накопилась приличная коллекция возражений против меня самого. Это архитекторы, аналитики, руководители разработки — люди, которые платформу не продают. Часть этих разговоров я тут перескажу, кое‑где даже дословно.

Дальше будет про то, где проходит граница между брокером и платформой, почему ее так трудно нащупать, почему настоящая причина «самописа» вообще не техническая и что во всей этой истории изменил ИИ. По последнему пункту спойлер: ничего хорошего.

Монолит документооборота, менеджмент говорит: «пора пилить на микросервисы». Мы нарезали шесть сервисов, сверху повесили API Gateway, Load Balancer и Circuit Breaker и какое-то время искренне считали, что теперь у нас взрослая распределённая система.

По факту мы собрали распределённый монолит. Те же зависимости, что и в монолите, только теперь по сети — с таймаутами, ретраями и без общей транзакции. Оно работало, спорить не буду. Просто каждая вторая проблема в итоге упиралась в одно и то же: границы сервисов мы провели не там, где надо.

Это не туториал «как правильно резать монолит на DDD-bounded-context за 10 шагов» — таких на Хабре хватает. Это разбор конкретных мест, где границы у нас поехали, в порядке от «это все знают, но всё равно наступают» до «поняли только в проде под нагрузкой». Если вы сейчас режете свой монолит — читайте как чеклист. Если уже прошли — сверьте, сколько совпало.

Дисклеймер: проект под NDA. Названия сервисов, домен и детали обобщены и изменены, часть цифр округлена. Сами грабли и порядок, в котором мы на них наступали, — настоящие.

Что полезного может делать бизнес-процесс, в котором всего одна задача, и та пользовательская? Что можно рассказать про BPMN-схему, которая поместится на экране смартфона? Муки выбора, драма, предательство и обстоятельства непреодолимой силы — вот что! Я расскажу, как на самом деле разрабатываются BPMN, исполняемые в движках вроде Camunda и Flowable, и, может быть, вы перестанете считать их просто «очередной графической нотацией»