Что это?

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

Я подобным образом в UML ER диаграмме разделяю объекты бд по доменным областям. Либо ещё можно разбивать таким образом в гибридной BPMN-диаграмме этапы обработки поступающих данных.

Я могу быть не прав, но сперва надо вроде понять, какие ресурсы есть у разработки. Возможно MVP следует выполнить в рамках монолита, т.к.  это сэкономит время и у даст больше возможностей при тестировании, изменениях, транзакциях. А потом распиливать на приложения, в рамках гибкой разработки, отчуждая доменные области в отдельные сервисы.

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

Но опять-же, я кусочек архитектора, а не целый архитектор, так что могу быть не прав. =)

Коллеги, добрый день. Скажите, пожалуйста, кто-нибудь использует на практике IT4IT? Поискал в интернете большинство публикаций трёх-четырёхлетней давности, хотелось задать пару вопросов о практическом применении.

Там надо альтернативы рассматривать комплексно. Ключевые риски:
Срок первичного внедрения
Ресурсозатратность на внесение изменений
Срок потери компетенций
Срок потери сопровождаемости.

Ну и соответственно все факторы которые влияют на это вот всё.

я подобные вопросы задавал тем кто уже работает в отрасли, некоторые сказали что архитектура была уже когда они пришли - то есть неизвестно кто и когда ее создал

Почитать - ну domain driven design вам в помощь.
Вообще, мне в целом кажется преждевременным разбивать на аппы структуру, не имея понимания, как будут использоваться данные. Разбивать их по областям и минимизировать связность - можно. Но вполне вероятно, что есть части в рамках одной потенциальной компоненты связности, которые, например, будут использоваться на несколько порядков чаще, чем другие. И тогда имеет смысл их выделить и выбрать, например, вообще другу технологию хранения и доступа к данным

На эту тему даже был вебинар у @mxsmirnov

схему в таком разрешении что ничего не прочитать в ее содержимом,
нет смысла комментировать - будет как лечение по фотографии

Удивительно как много уже написали. Представляешь, если бы на картинке ещё можно было что-то прочитать?! Хороший чат. 😊

Интересная картинка. Максимальная прибыльность находится в точке оптимального уровня качества, а не в точке идеального качества.
Под затратами на этой картинке подразумеваются затраты на обеспечение качества.

оффтоп:
вышел уже второй пререлиз Archi 4.7:
https://www.archimatetool.com/downloads/beta/change-log.txt

на высокой точке зеленого графика бизнес сворачивает удочки

👍🏻
Интересно, когда будет релиз.

молчат.... и как-то странно - из роадмапа сделана по факту только половина 😞

Т.е. еще ~ месяца 3 где-то. Но функции новые - очень интересные.