Типа юзать всякую залупу для вызова js из джавы?

микросервис валидации запилить) на ноде

Ох, это уже выглядит как ненужный гемор. Лучше уже алгоритм 2 раза написать)

Или проксировать через js.
Или просто делать что надо и отправлять сообщение дальше.

Не пилите микросервис. Это компонент приложения но не микросервис. Как и ваш фронт такой же компонент. Оно не сможет быть независимо задеплоено.

Хуевый бизнес план если у тебя нет цели паралельно ещё один продукт запускать

Валидация — это не самостоятельная предметная область, зачем ей микросервис отдельный?

Если ttm доработки напильником чего-нибудь решения с github неделя, то почему бы не выпустить да посмотреть на реакцию рынка?

Коллеги, привет!
В DDD считается, что на один Aggregate должен быть один репозиторий. Но как быть, если в рамках одного агрегата его корень и части находятся в разных местах. Например: корень в БД, атрибут в виде VO где-нибудь в Redis, а ещё одна сущность на стороннем API. Но фактически это один агрегат с точки зрения бизнеса. Выходит мне нужно делать такой репозиторий, который внутри себя аккумулирует ещё 3 репозитория?

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

1. Разумеется. Вот я задал интерфейс для агрегата. А как реализовывать этот интерфейс, если разные части в разных местах?
2. Очень просто. Запросами в хранилища.

Видимо нужен будет механизм транзакций между этими хранилищами

Вообще довольно странный кейс. Стоит задуматься над тем имеет ли такой агрегат смысл вообще.

Я же не спрашиваю как мне целостность сохранить. Вопрос в другом.

Скорее всего это и не агрегат вовсе

Агрегат - это граница транзакции. То есть ситуация когда у тебя "части агрегата в разных местах" означает что у тебя много агрегатов а не один. Разные хранилища подразумевают eventual consistency. Так же как в ситуации когда один агрегат дает гарантию imidiate consistency и общую целостность системы ты уже eventually как-то делаешь.

не надо путать "сущность" и "агрегат".

простой способ понять где у тебя граница агрегата пролегает - определить какие данные нужны для проверки некого инварианта системы где тебе прям надо imidiate consistency. То есть мы говорим о неком объекте который как правило весь свой стэйт юзает в операции (или большую его часть).

Если у тебя у агрегата десяток операций и каждой нужны разные поля - надо дробить

Такой вопрос. Вы делаете валдиацию данных на беке, которая нужна чисто для ограничения размера? Типа макс. длина описания или email и тд. Или полагаетесь на констрейнты в базе?

есть ограничение размера тела запроса и хватит)