Понял) Тогда другой вопрос. Уместно ли их хранить в словарях или их стоит вынести в отдельный микросервис?

Мне кажется в формате словарях норм, но не претендую на объективность

Спасибо) И ещё последний вопрос. У меня участники и представители в регистрации могут создаваться другим пользователем, например, представителем. То есть участника могут регистрировать хоть родители.

Сейчас я сделал так, что всех людей в системе создаём в Person, а потом связываем Person с Аккаунтом. Person !== User.

Имеет ли смысл разделить с дублированием данных? И в регистрации указывать не только связь на PersonID, но и свои данные: фио, дата рождения, пол и так далее. То, что нужно этому микросервису.

Получится так, что создаём участника и если нужно связываем с аккаунтом. Но для работы этого микросервиса есть все данные. В таком случае мы можем разделить связанность в микросервисах

Надеюсь понятно объяснил)

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

Интересно узнать мнения и других, не считаю себя профи в таких вопросах

С точки зрения персональных данных, конечно, лучше в одном месте. С этим не поспоришь. Но тогда все микросервисы работающие хоть как-то с человеком будут зависеть от Person. Просто видел такие практики в ограниченном контексте когда сущность User везде разная и имеет свои данные. Например, в комментариях это Комментатор и ему нужно только имя. В блоге это Автор и ему нужно только имя. В доставке нужен только телефон и имя. В итоге мы получаем в каждом микросервисе свою сущность человека и необходимы данные для микросервиса. И теряется связь.

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

Вообще делая микросервисы надо очень хорошо задумываться сколько раз один сервис будет обращаться к другому в рамках одного сценария запроса от пользователя.  Http запросы очень долгая штука

Раньше я делал подобную систему без микросервисов. В Монолите. Где были границы ограниченных контекстов.

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

Поэтому и чешу голову) и не могу принять решение как лучше. И там и там минусы и плюсы)

И это тоже понимаю. Поэтому и говорю, что у меня практически все микросервисы будут завязаны на Person. Так как практически везде люди и их много. При этом разные роли. Но и не думаю что это плохо. ВК как то живет и ничего)

Просто может легко получится, что в одном сервисе есть пользователь, а другой микросевис будет думать что его нет

Это надо принять и с этим жить

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

Если бизнес логика такое позволяет или строить дополнительные механизмы досинхронизации данных..  то все ок

А на счёт как лучше, все зависит от задачи и от цены ошибки, если  скажем 1 из миллиона пользователей потеряется, не сможет записаться  на  сколько это плохо?

Понял)) Наверное, лучше хранить изначально все в Person, а с ростом системы подумать стоит ли разделить. Разделить всегда легче, чем потом собрать. Особенно если таких данных будет много и они могут быть продублированы)

Спасибо за ночную помощь!)))))

Ох... разделить вообще не легче )

Слишком много всего будет завязано на этих данных

Авито уже несколько лет занимается разделением судя по их рассказам ))

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