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

зрения инкапсуляции и типизации?
Есть Book{id,name} и Page{id, bookId, pageNumber,,text}. С фронта прилетает массив [{pageNumber, text}, {pageNumber, text}].
Нужно запилить изменение страниц у Book: если есть - изменить текст, если есть/нет - удалить/добавить соотвествующие страницы.
Верно ли я понимаю, что у Book должны быть следующие методы?
Book->addPage(pageNumber, text); // тут ищем в коллекции страницу, если есть - exception, иначе добавляем
Book->removePage(pageNumber); // тут ищем в коллекции страницу, если нет - exception, иначе удаляем
Book->editPage(pageNumber, text); // тут ищем в коллекции страницу, если нет - exception, иначе меняем текст
Book->updatePages(...PageInfo) // Тут делаем разбор по коллекции страниц, сравниваем с тем что прилетело и вызываем addPage/removePage/editPage. PageInfo{pageNumber, text} - некая inputDto в области модели (а не юзкейса рядом с командой), которая содержит данные о странице, но не содержит bookId необходимый для валидного Page.

Вопрос: верно ли я решаю данный кейс и не является PageInfo (или это Embeded VO внутри Page как раз? ), либо что-то еще - лишним, либо наоборот чего не хватает.

а для чего в кейсе pageNumber?

Ну у страницы же есть номер

это номер страницы в книге?

Да

смотри на lack of cohesion метрику класса, хз. кто тебя знает правильно или нет. мы ж ничего не знаем про инварианты и т.д. выглядит как тупой круд а значит "любой вариант будет работать"

я не так давно, после беседы с Сергеем, перешла на следующую модель своих приложений, опишу на твоем примерее... делаем сущность Page{id, bookId, texId}, отделяем текст в сущность к примеру TextPage{id, text} TextPage - всегда создаем, никакого remove, только обновляем texId в сущности Page какой профит - мы можем откатить изменения, мы можем отследить изменения, никакой конкуренции, ну и кучу еще чего можем связать

Спасибо. А вмсысле нет конкуренци?

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

Вообще подход интересный для истории.

И что это дает? У нас две операции на update id, одна из них сразу перетрется второй. Но да, insert останется в истории, но толку от него

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

Могу, а нужно ли это?

смотри свой кейс ))

ну мне нравится подход тем что ты можешь из него выкинуть версионизацию и оставить просто коллекцию страничек, остается всеравно мозможность более гибко всем управлять. А book будет репозиторием))))

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

запрос на insert+1 - никак не затронет твою запись, она не заблокирует, в то время когда ты будешь просто апдейтить

мы все равно updateid делаем