Хм, при чем тут разработка и сопровождение? И какие пользователи СМЭВ имеются в виду? Вообще, те, кто пользуются СМЭВ - знают, что это общий интерфейс c кучей разных продуктов, почему это "один продукт"?
У МСА вообще нет нормального определения. По большинству МСА - это про автономность (которой не бывает), независимость деплоя (которой тоже не бывает) и современные методы коммуникаций. Ну и DDD - не про разделение по доменам, это про выделение доменов и контекстов, а уж как это мапится на приложения - не важно.
А почему с "общими данными"? У разных продуктов как раз очень мало общих данных, при нормальном проектировании - вообще никаких кроме некоторых идентификаторов.
И да, всякие MDM - это как раз отдельный продукт.
СМЭВ - это продукт поверх других продуктов, так-то там каждое министерство со своей информационной системой, а СМЭВ - это шина обмена, не более.
Хм, мобильное приложение банка - не продукт, а интефейс к разным продуктам. Вот эмиссия и эквайринг - разные продукты. Кредитный конвеер - отдельный продукт почти всегда. И какой-нибудь "доступ к бизнес-залам" - отдельный продукт (хотя обычно очень небольшой). А если посмотреть на приложение чего-нибудь типа T-банка, то там куча разных продуктов (к банку вообще не имеющих отношения).
Сделать несколько разных приложений. Собственно, DDD (в нормальном использовании) как раз про это - и не связано особенно с МСА. А вот где проводить границу "разные продукты/домены или один" - зависит как раз от размера, опытности команд и прочих внешних факторов.
Увы, категорически нужно угадывать несуществующие требования, это одно из основных занятий архитектора. Иначе система становится невозможной к развитию. Приходится думать и об изменении НФТ и о расширении ФТ. Да, иногда бизнес может в этом помочь, но архитектор вынужден знать предметную область не хуже бизнеса, увы.
В МСА как раз ttm резко взлетает, по сравнению с модульным монолитом. Вот от 200 человек - да, монолитом сложно управлять. Но это проблема не в монолите, а в попытке в одно приложение упаковать несколько разных продуктов.
А при чем тут монолит? И как микросервисы спасают от этих же проблем. Если разработчики некомпетентны даже в использовании интерфейсов, то откуда возьмется компетенция в создании распределенных систем? Все те же проблемы постоянно вылезают и в МСА.
Команда в 100 человек крайне редко делает один продукт. Обычно реально там много продуктов (и много монолитов). Ну и скорее всего про модульность никто и не думал никогда (впрочем, в МСА - тоже обычно никто не умеет в нормальную изоляцию, так как это сложно).
Хм, релизы монолитов бывают и по три раза в день, в чем проблема-то? Да и релизы многосервисных систем (МСА тут не при чем) бывают по полгода делают.
Релизы и архитектурный стиль крайне мало связаны. И МСА никак не решают проблему ускорения релизов. Мода на МСА к релизам никак не привязана. Собственно, как и любая мода - она никак не связана с прагматичными соображениями.
Это, увы, иллюзия. Во-первых, снижать когнитивную нагрузку можно и модулями, микросервисы тут не обязательны. Во-вторых, любая распределенная система на порядки сложнее и при разработке микросервиса приходится думать про все эти сложности, так что программисту становится только сложнее. Ну и кто-то должен думать о создании контракта и если программист занимается "лишь конкретной функциональностью", значит кто-то другой подумал про прочую часть системы.
Да, можно плюнуть на качество (что обычно и происходит в распределенных проектах, где считают, что можно съэкономить на программистах), но в таком случае и в монолитах (или других видах распределенных систем) будет не сложно.
Хм, дашборд сверху-вниз: 1. Плашка с моим именем (бесполезная информация, где-то в 10% высоты) 2. "Пульс" - социальная сеть Т-банка (бесполезная, где-то 25% высоты) 3. Плашка "Все операции" и "Кэшбек". Где-то 25% высоты, содержание бесполезно (сумма трат за месяц и ссылка на страницу с предложениями партнеров) 4. Список возможных операций, 10%, полезное 5. Список карт. На экране влезает только одна карта, за остальными уже нужно скроллить
Ниже - (уже второй и дальше экраны) - список рекламных ссылок на сервисы банка, рекламные ссылки на предложения партнеров.
Т.е. полезной информации на дашборде: 25% и не влезают данные даже по двум счетам. Всего на дашборде полезной информации практически нет.
Это про очень, очень плохой UX и очень кривой дизайн. У Сбера на дашборде на первом экране где-то 60% полезной информации, на первом экране вообще все более-менее полезное. Вообще, все мне известные приложения - спроектированы лучше.
Ну вот при переводе по номеру телефона подтягивается клавиатура с отключенным русскими языком (Android). Что делает поиск по адресной книжке полностью бесполезным. При открытии приложения где-то один раз из 10 вообще никакие виджеты не отображаются, приходится пробовать еще раз (судя по всему - какие-то гонки на инициализации) Виджеты с социальной сетью (хотя нафига мне их социальная сеть, занимающая треть дашборда) регулярно вообще пустые. Ну и так далее и так далее и так далее.
Вообще, приложение выглядит довольно устаревшим - и по дизайну и по функциональности (второе, наверно, связано с техническими возможностями их процессинга).
Проще отправить эти 1000 строк на клиента - и не заставлять API зависеть от UXа клиентского приложения (которое может завтра поменяться). Но тут уже нужно говорить о паттерне bff, о проектировании системы целиком, о качестве API - все то, что явно не попадает в контекст данной статьи (которая вообще не про качество API и не про качество реализации)
Ну, почему не получалось переходного периода - понятно. В Росбанке вряд ли были готовы к импортозамещению, а с 01.01.25 Тбанк (как системообразующий) был обязан уже перейти на подходящий софт. Так что пришлось переводить побыстрому. Но качество перехода и его тестирования - да, печальное.
Хм, при чем тут разработка и сопровождение? И какие пользователи СМЭВ имеются в виду?
Вообще, те, кто пользуются СМЭВ - знают, что это общий интерфейс c кучей разных продуктов, почему это "один продукт"?
Тогда поясни, про какие блокировки ты говоришь при ожидании транзакций?
И как шардирование может решать проблему транзакций?
У МСА вообще нет нормального определения. По большинству МСА - это про автономность (которой не бывает), независимость деплоя (которой тоже не бывает) и современные методы коммуникаций.
Ну и DDD - не про разделение по доменам, это про выделение доменов и контекстов, а уж как это мапится на приложения - не важно.
А почему с "общими данными"? У разных продуктов как раз очень мало общих данных, при нормальном проектировании - вообще никаких кроме некоторых идентификаторов.
И да, всякие MDM - это как раз отдельный продукт.
СМЭВ - это продукт поверх других продуктов, так-то там каждое министерство со своей информационной системой, а СМЭВ - это шина обмена, не более.
Хм, блокировка чего нужна при ожидании транзакции? Узкое место - как раз IOPSы и ядра в БД.
Но, заметим, шардирование не решает проблему транзакций.
Хм, мобильное приложение банка - не продукт, а интефейс к разным продуктам.
Вот эмиссия и эквайринг - разные продукты.
Кредитный конвеер - отдельный продукт почти всегда.
И какой-нибудь "доступ к бизнес-залам" - отдельный продукт (хотя обычно очень небольшой).
А если посмотреть на приложение чего-нибудь типа T-банка, то там куча разных продуктов (к банку вообще не имеющих отношения).
Сделать несколько разных приложений.
Собственно, DDD (в нормальном использовании) как раз про это - и не связано особенно с МСА.
А вот где проводить границу "разные продукты/домены или один" - зависит как раз от размера, опытности команд и прочих внешних факторов.
Увы, категорически нужно угадывать несуществующие требования, это одно из основных занятий архитектора. Иначе система становится невозможной к развитию.
Приходится думать и об изменении НФТ и о расширении ФТ. Да, иногда бизнес может в этом помочь, но архитектор вынужден знать предметную область не хуже бизнеса, увы.
В МСА как раз ttm резко взлетает, по сравнению с модульным монолитом.
Вот от 200 человек - да, монолитом сложно управлять. Но это проблема не в монолите, а в попытке в одно приложение упаковать несколько разных продуктов.
А при чем тут монолит?
И как микросервисы спасают от этих же проблем. Если разработчики некомпетентны даже в использовании интерфейсов, то откуда возьмется компетенция в создании распределенных систем?
Все те же проблемы постоянно вылезают и в МСА.
Команда в 100 человек крайне редко делает один продукт. Обычно реально там много продуктов (и много монолитов). Ну и скорее всего про модульность никто и не думал никогда (впрочем, в МСА - тоже обычно никто не умеет в нормальную изоляцию, так как это сложно).
Хм, релизы монолитов бывают и по три раза в день, в чем проблема-то?
Да и релизы многосервисных систем (МСА тут не при чем) бывают по полгода делают.
Релизы и архитектурный стиль крайне мало связаны. И МСА никак не решают проблему ускорения релизов.
Мода на МСА к релизам никак не привязана. Собственно, как и любая мода - она никак не связана с прагматичными соображениями.
Это, увы, иллюзия.
Во-первых, снижать когнитивную нагрузку можно и модулями, микросервисы тут не обязательны.
Во-вторых, любая распределенная система на порядки сложнее и при разработке микросервиса приходится думать про все эти сложности, так что программисту становится только сложнее.
Ну и кто-то должен думать о создании контракта и если программист занимается "лишь конкретной функциональностью", значит кто-то другой подумал про прочую часть системы.
Да, можно плюнуть на качество (что обычно и происходит в распределенных проектах, где считают, что можно съэкономить на программистах), но в таком случае и в монолитах (или других видах распределенных систем) будет не сложно.
Да и не должен аналитик подменять собой UI/UX специалиста, зачем?
Хм, дашборд сверху-вниз:
1. Плашка с моим именем (бесполезная информация, где-то в 10% высоты)
2. "Пульс" - социальная сеть Т-банка (бесполезная, где-то 25% высоты)
3. Плашка "Все операции" и "Кэшбек". Где-то 25% высоты, содержание бесполезно (сумма трат за месяц и ссылка на страницу с предложениями партнеров)
4. Список возможных операций, 10%, полезное
5. Список карт. На экране влезает только одна карта, за остальными уже нужно скроллить
Ниже - (уже второй и дальше экраны) - список рекламных ссылок на сервисы банка, рекламные ссылки на предложения партнеров.
Т.е. полезной информации на дашборде: 25% и не влезают данные даже по двум счетам. Всего на дашборде полезной информации практически нет.
Это про очень, очень плохой UX и очень кривой дизайн. У Сбера на дашборде на первом экране где-то 60% полезной информации, на первом экране вообще все более-менее полезное.
Вообще, все мне известные приложения - спроектированы лучше.
Ну, это все занимает львиную долю на дашборде, увы.
Ну вот при переводе по номеру телефона подтягивается клавиатура с отключенным русскими языком (Android). Что делает поиск по адресной книжке полностью бесполезным.
При открытии приложения где-то один раз из 10 вообще никакие виджеты не отображаются, приходится пробовать еще раз (судя по всему - какие-то гонки на инициализации)
Виджеты с социальной сетью (хотя нафига мне их социальная сеть, занимающая треть дашборда) регулярно вообще пустые.
Ну и так далее и так далее и так далее.
Вообще, приложение выглядит довольно устаревшим - и по дизайну и по функциональности (второе, наверно, связано с техническими возможностями их процессинга).
Проще отправить эти 1000 строк на клиента - и не заставлять API зависеть от UXа клиентского приложения (которое может завтра поменяться).
Но тут уже нужно говорить о паттерне bff, о проектировании системы целиком, о качестве API - все то, что явно не попадает в контекст данной статьи (которая вообще не про качество API и не про качество реализации)
Хм, а как можно было решить эту проблему с вашей точки зрения?
Ну, почему не получалось переходного периода - понятно. В Росбанке вряд ли были готовы к импортозамещению, а с 01.01.25 Тбанк (как системообразующий) был обязан уже перейти на подходящий софт. Так что пришлось переводить побыстрому. Но качество перехода и его тестирования - да, печальное.