@odomontois
Взаимодействие с биржей это совсем не то же самое что и микросервисная архитектура и там по другому чуть.

Я все же вернусь к микросервисам:
Если в нескольких микросервисах есть одни и те же данные и они в нескольких микросервисах могут меняться, и их после этого нужно синхронизировать - так точное делать не нужно.

Если в сервисе ордеров нужно принимать решение на основе каких-то данных о согласованиях, у него могут быть эти данные, только это даже не будет отдельной доменной моделью.
Это могут быть какие-то айдишки без проблем, это может быть, например, количество согласований связанных с этим ордером. Пришел ивент "юзер чёт согласовал по ордеру номер 355" - инкрементнули циферку

Но ты так и не описал кейс. Бывают штуки которые зависят от кучи данных в разных сервисах как тут, например - https://youtu.be/Fuac__g928E

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

Ну так привлекло "его стараниями" или "его (в т.ч.) стараниями"?

ну я как-то не базарю в стиле - а ты знаешь кто он такой )) поэтому и не сучка, мы с Евгением и Олегом общались норм

я примерно знаю, что такое взаимодействие с биржей

@odomontois По сути ты вывел проблему Анемичных моделей на уровень сервисов, нужно как-то инкапсулировать принятие решений в том модуле который владеет информацией нужной для решения(привет, кстати information expert из грасп)

И сорри, я с телефона пишу и могу путататься

я чуть чуть пописывал кот в нашем трейдинге

понимаешь, нет проблемы анемичных моделей

есть проблема мутабельности

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

Сложно сделать за инвариантами стейта если он меняется в нескольких местах

для этого надо ивенты слать

Да, ивенты они как раз про декаплинг

но ты говоришь, что нельзя шарить данные. некоторые - можно

так в том и суть, что современные архитектурные проблемы автоматически приводят к иммутабельным моделям и верификации при конструкции

Если я недавно учился, это не означает что я тупой и чего то там не понимаю, и делаю голословные утверждения - нет. Мне не нужно набивать шишки и наступать на грабли чтобы понять что что-то есть фигнёй. Очень большое количество граблей не зарытых глубоко за 3-4 слоями абстракций  я могу вычесать до фактического наступания.

идея в том, что имея не очень много навыков ФП можно спокойно согласовать с этим несколько независимо существующих приложений

А не имея совсем, прикрываясь инкапсуляцией под иллюзией контроля как раз автоматически события развиваются в сторону расходящихся неконсистентных моделей

Можно пожалуйста выжимку