И единороги с радугой! Единороги же!

Там написано про «+10 кг» — трудно будет поддерживать.

Резюме выглядит как-то странновато, не факт, что так хорошо. Доучи какой-то популярный фреймворк (ангуляр, реакт, что-то еще), возможно сделай какой-то более сложный пет-проект чем страничка, которая везде ссылается сама на себя и будет больше шансов найти работу.

четыре из трёх.

У меня как-то раз была просрочка по уплате налогов (не успел оплатить вовремя). Так уже через несколько дней после факта просрочки меня ждало «письмо счастья» с уведомлением о вручении, в котором подробно описывалось что я лось, что именно я сделал не так и на сколько попал в деньгах. Так что если таких писем по месту регистрации ФОПа (по месту прописки) нету, то по идее волноваться не о чем.

Тут можно вернуться к моему призыву руководствоваться здравым смыслом в рамках понимания рич и анемик моделей, и доменной модели, ведь любая аппликуха является (должна являться) и отображением реального бизнеса, который за ней стоит. Вместо того, чтобы ломать копья какая книжка или теоретическая статья лучше. Сейчас как раз много думаю на эту тему: ведь в реальном мире (по крайней мере в моем кейсе) нельзя быть просто погромиздом, нужно разбираться и доменной области бизнеса для которого пишешь код. Т.е. по хорошему нужно быть техническим экспертом для решения проблем бизнеса, а для этого нужно в этом самом бизнесе разбираться и понимать что в нем важное / главное для клиента, а с чем можно подождать или вообще забить. И этот вопрос для меня сейчас самый сложный, а не попытки понять куда какую сущность запихнуть или где какой метод / функционал должен быть расположен. Ведь когда ты понял бизнес клиента (на своем уровне конечно), вопросы типа «куда запихнуть этот долбанный функционал?» как-то отпадают сами собой.
АПД: Выше я какбы намекаю на то, что: что явлется инвариантом чего или частью, или связанным в один контекст, или не связанным, должен диктовать бизнес (его модель), а не техническая теория. Ведь мы технически пытаемся отобразить бизнес, а не пытаемся натянуть сову на глобус, бездумно следуя технической книжке или набору технических статей. Ну по крайней мере должны пытаться :)
Ну и продолжая на конкретном примере про сумму заказа: А почему она должна быть быть частью именно заказа? Почему бы ей не быть привязанной к Юзеру, т.к. деньги за заказ (эту самую сумму) платит юзер? Учитывая, что для расчета этой суммы мы обязательно еще должны «заглянуть» в скидки, которые тоже часть юзера и определить сколько именно этому юзеру надо заплатить денег в данном конкретном случае.
Или еще вариант родился: Пусть сумма будет частью заказа (допустим нас и так устраивает), а Заказ частью Юзера (как и скидки), тогда для расчета суммы заказа (с учетом возможной скидки) у нас есть все данные на уровне Юзера.

Мой вариант начался бы с вопроса: «Если расчет скидки подразумевает работу с бОльшим количеством объектов типа „Заказ“, чем один, должен ли этот метод быть внутри заказа?»
Я бы скорее всего его вынес в какой-нибудь РасчетСкидокСервис, который работал бы со списком заказов и рассчитывал бы их для юзеров.
Ведь скидка — это не про заказ. Это про юзера, который сделал несколько заказов. И получает скидку не заказ, а юзер. Или не получает. :)
Вспоминая логику, возможно сделал бы отдельное поле юзеру «Скидка», в котором бы держал пересчитываемую информацию о том, накопилась ли у него уже скидка, если да, то какая.
Ну и конечно Сервис держал бы в себе внешние зависимости про репозиторий и если еще что-то надо.
АПД: Мыслями навеяло. Расчет скидки даже наверное был бы ближе к внутренностям объекта юзера, ведь он предварительно должен в себе содержать всю нужную информацию про историю заказов этого самого юзера. Если нет — то юзер сервис, который будет находить эту самую историю и по ней считать скидки.

Зависимости — это внешние по отношению к объекту (и аггрегата в т.ч.) сущности. Соответственно зависимости — удел сервисов и аггрегатов. Если мы достаем данные нужные для чего-то извне объекта, то и зависимости должны находиться вне объекта — в сервисе, аггрегате.
Как и методы, которые работают используя эти самые зависимости.
Внешние для аггрегата зависимости для доставания внешних для аггрегата данных — вне аггрегата (в его сервисе, аггрегате аггрегата). Да, получается «капуста», но без крайних состояний как в сторону Бугаенко, так и без крайних ситуаций, когда объект модели данных является просто переносчиком данных в анемичной модели. Но это все про близкие по духу зависимости, которые ограничиваются баундед контекстом.

Начни с просто спринга (Core он же IoC Container) потом уже поймешь, что все остальные спринги (Boot, Data, Security, etc) это его подпроекты и, зная основу, с остальным управишься быстрее / легче. Можешь заодно посмотреть в сторону SOLID принципов — они хороши для разработки на любом языке.

А если попробовать поговорить про здравый смысл с учетом знаний про ООП, ДДД и рич вс анемик модели данных?
Если сказать что в соответствии с ООП и рич моделью объект должен знать что и как делать с собой любимым (проверки / валидации, апдейт своего состояния (если нужно) и т.д.)?
А все, что вне объекта (работа с хранилищем данных для этого объекта, трансформация его в другие форматы данных ((де)сериализация) это работа для внешних для этого объекта сервисов?
Не решит ли это большинство проблем?

Помню-помню как вы предлагали ранее другую анкету «давай ты нам напишешь и мы тебе кААААк поможем с поиском супер работы!». Даже заполнил и отправил. И уже с год тишина... Хороший сервис. Продолжайте в том же духе :)

Стоит ли забирать военный билет?

Смотря у кого. У МС по боксу не рекомендовал бы.

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

Проходить!

То времени нет, то сил, то снова времени, то сил. Иногда еще желания нет, но редко.

Для более пятничного отображения темы предлагаю немного изменить знаки препинания.
Новый смысл выглядит гораздо более пятнично :)

та ця тема має інших, — характер! :)

Не успел прочитать все комменты, может кто уже и написал где:
Интерфейс — это контракт на поведение.
Он позволяет уменьшить связанность классов: твой класс Клайент теперь ничего не знает о реальной реализации метода пей, он знает что при его вызове произойдет этот самый пеймент. Ему не нужно знать подробностей( куда будет платиться, что еще будет вызываться для реализации платежа и т.д.)
И вот использование интерфейса дало тебе возможность гораздо легче вносить изменения: тебе надо заменить метод пеймента на ПейментЧерезКассуВБанке() и тогда тебе не нужно будет ничего менять в клайенте.
Тестировать такое тоже гораздо легче.
А вот применение в твоем примере не очень:

//тут я понимаю, что могу создать
payment = new card или paypal или webmoney;

надо заменить на какой-нибудь @Autowired этого же интерфейса и IoC контейнер сам найдет и вставит тебе текущую реализацию.
Тут рекомендую больше почитать про инверсию заисимостей.
P.S. Выгода от такого подхода почти не видна на таких маленьких примерах.
Задумайся если у тебя будет 200 классов большинство которых будет знать друг о деталях реализации поведения друг друга и тебе нужно будет внести изменения в один из них — сколько классов в итоге реально затронут изменения?
И та же ситуация среди классов, где они взаимодействуют друг с другом через интерфейсы, даже не подозревая как там у остальных реализовано это поведение.

Меня в свое время настолько утешил "Утешен, что я решил не продолжать поиск дальше :)

А у вас есть собака?

Просто будь собой на собесе. По идее он должен тебя оценивать насколько ты впишешься в команду, насколько ему будет удобно тебя менеджить и с тобой работать. И беседа скорее всего будет представлять собой обмен мнениями о построении и настройке рабочего процесса в команде, на проекте и в компании. Сойдетесь по основным подходам — будет оффер, окажется, что очень по разному смотрите на эти вещи и оба не готовы переходить на новый для себя подход — не будет оффера.
Как-то так.