Продолжаю работу с ментатами 🤓

Кажется, уже пора рефакторить, потому что архитектура получилась не такая гибкая, как я планировал)

Ну да, и это при том что мы ещё по сути и не начинали :)
"Дипломный проект", 7-е задание из 45.

...Очень нравится, как голова разгружается после таких задач - то, что было запутанно и нечетко, обретает понятную форму.

...не рассчитал время и график - завалили

Я уже не раз на эту тему говорил, все свои любые сроки-прогнозы, пусть даже самые пессимистичные на ваш взгляд, сразу умножайте x2 x3, тогда получите самую оптимистичную оценку :)
Классическая рекомендация - Голдратт "Критическая цепь"

...Очень частый паттерн в реальных Go-репозиториях (Uber, многие внутренние сервисы на github, шаблоны типа golang-standards/project-layout): для каждого struct, у которого нужен мок в тестах, через mockery/moq механически генерируется интерфейс
Это ровно "Extract Interface": единственная продакшн-реализация -- orderService, интерфейс существует только ради DI/мокирования в юнит-тестах, а не потому что появилась вторая содержательная реализация.

...Но когда я разбиралась с Hibernate для данного задания, я выяснила интересную вещь: из-за того, что объект Entity не содержит бизнес-логики, мы не используем многих фичей Hibernate, таких как dirty checking, lazy loading.
И в нашем случае вместо Spring Data JPA можно использовать Spring Data JDBC. Он вообще не использует Hibernate. Вот его уровни:
Spring Data JDBC -> JdbcTemplate (надстройка Spring над plain JDBC)-> JDBC -> Postgres
В то время как Spring Data JPA:
Spring Data JPA -> EntityManager -> Hibernate -> JDBC -> Postgres
Не будет накладных расходов на прокси, n+1. При этом, это будет тот же удобный CRUD Repository, к которому привыкла команда, но без накладных расходов ORM.

...Мы выражаем моками абстрактные эффекты низкого уровня, чтобы проверить какой-то другой абстрактный эффект текущего уровня. Тем самым мы отвязываемся от реализации, закладываясь на положения спецификации. И опять возникает ощущение, что тут раскрываются идеи "трёх уровней думания о программе".

...После понимания, что у нас есть уровни, до меня сейчас дошло, что не надо думать обо всех уровнях сразу, и вспомнил про bottom to top проектирование на ООАП3. В принципе, на данном этапе, мне кажется это и к фп тоже применимо, тк каждый уровень предоставляет типы, функции, и мы просто потом используем его. Потому что я прямо зависал по долгу над тем как "всё оно вместе" должно общаться. Сразу после понимания уровней это не пришло. Тут конечно надо дальше менять мышление, потому что программировать только один уровень, и не думать о 10 других почему то трудно.