DT
А упд не может быть просто уникальным номером, который объединит эти доки в случае когда надо?
Size: a a a
2021 August 20
DT
Зачем докам быть внутри упд?
ЕК
сейчас эти доки имеют айди упд, поле nullable, т.е. может не быть связи с упд, т.е. документ сам по себе
DT
Доки в баундед контексте доков это скучно. Они либо есть либо нет. Во всех остальных контекстах хватит айдишки дока и допинфы которая важна именно в другом контексте но абсолютно точно не важна в границах контекста документов
DT
Оставь доки в доках, а упд вынеси куда и разверни связь чтобы не доки имели связанный с ним упд, а упд был коллекцией документов (или только их айди ), тогда и нуллабл булщита у тебя не будет
DT
Документ он документ. Когда тебе нужен документ ты идёшь в документы. Когда тебе важно упд ты идёшь куда нибудь ещё, но за это документы точно не должны отвечать
DT
Когда я говорю "точно должны" я имею ввиду с моей колокольни выглядит ткк
ЕК
вот да, была такая мысль, что связь не с той стороны
DT
Ты просто мыслями завязался на реляционную модель
DT
потому что скорее всего это все и будешь хранить в реляционке
ЕК
не отрицаю) первый проект где пытаемся в ддд, а мышление все ещё старое
DT
доктрина как раз и существует, чтобы разорвать эту связь. Быть адаптером между тем как тебе удобно работать с сущностями (обычными объектами) в доменной модели и тем как оно будет раскладываться в СУБД (а это уже детали)
✨
вот тебе еще пример на твоем же проекте - не упд должен знать о доках, а доки об упд
DT
просто все привыкли юзать доктрину как отражение схемы БД в своем приложении, хотя она-то как раз наоборот, существует чтобы отражать сущности программного продукта на детали хранения (т.е. реляционную модель)
ЕК
наоборот может?
✨
нет, именнно так как описала
ЕК
так только что обсуждали это) что как раз таки упд хранит ссылки на доки, входящие в него
ЕК
а доки сами по себе
ЕК
или я туплю уже)
✨
упд у тебя может быть связь с доками, а может и null, поэтому ей незачем знать о доках, тебе достаточно докам знать о своей упд