Хорошая статья! Но не всегда думаю стоит разносить по отдельным модулям (если это не оправдвно только). Сам пару лет назад попробовал гексагоналку и теперь практически любой новый проект пишу на ней, после заходишь через год в проект и сразу же видишь что где и как работает ! Ну да немного больше кода, маппинг между контроллером в домен, из домена в чущность - и обратно. Но эти затраты очень "окупаются" после! К тому же контроллеры чистые (в три строки), логика сразу понятна и отделена в useCases (без зависимостей, бины нужные создаются в конфигах), в домене все по DDD только там строится обьект и нигде иначе. И я разбиваю чуть иначе (но смысл тот же):
Что касается "вопросов котрые возникли у экспертов сообщества" - имеют место быть, да, но личное мнение, что они дополнительные, назову их моментами, ньюансами, и конкретной спецификой, которых впрочем может гораздо больше (из перечисленых).
Статья итак очень подробно описывает логику, спасибо за материал!
Хорошая статья! Но не всегда думаю стоит разносить по отдельным модулям (если это не оправдвно только). Сам пару лет назад попробовал гексагоналку и теперь практически любой новый проект пишу на ней, после заходишь через год в проект и сразу же видишь что где и как работает !
Ну да немного больше кода, маппинг между контроллером в домен, из домена в чущность - и обратно. Но эти затраты очень "окупаются" после! К тому же контроллеры чистые (в три строки), логика сразу понятна и отделена в useCases (без зависимостей, бины нужные создаются в конфигах), в домене все по DDD только там строится обьект и нигде иначе.
И я разбиваю чуть иначе (но смысл тот же):
├── adapters/│ ├── in/│ │ ├── consumer/│ │ ├── controller/│ │ │ ├── mapper/│ │ │ ├── request/│ │ │ ├── response/│ │ │ └── Controller*.java│ │ └── scheduler/│ └── out/│ ├── client/│ ├── geocoder/│ ├── repository/│ │ ├── mapper/│ │ ├── entity/│ ├── AdapterPersistence*.java├── application/│ ├── ports/│ │ ├── in/│ │ │ ├── command/│ │ │ ├── Job*.java│ │ │ ├── Create*.java│ │ │ ├── Get*.java│ │ └── out/│ │ ├── exception/│ │ ├── Job*.java│ └── usecase/├── config/├── core/│ ├── domain/│ ├── enums/│ ├── exception/│ └── factory/└── ApplicationСпасибо за статью, полезный и нужный материал !
"В следующий раз поработаем с
AvroиSchema Registryна практике изSpring Boot. " - К когда ждать ? )Просто "старые сеньоры-пердуны" не умеют пользоваться AI возможно )
Спасибо! Хороший пример! Но почему всетаки не кафка ?
Если Java 21 и выше то Томкат можно на виртуальных потоках стартовать что в разы даст прирост.
О спорах с гпт это вообще прям лишнее.
Немного похоже на новый велосипед
Кто знает какой библеотечкой(maven) можно в Java конвертировать HEIC ⇢ JPG без стороних api типо JDeli и подобных ?
Очень хороший и полезный материал!
Что касается "вопросов котрые возникли у экспертов сообщества" - имеют место быть, да, но личное мнение, что они дополнительные, назову их моментами, ньюансами, и конкретной спецификой, которых впрочем может гораздо больше (из перечисленых).
Статья итак очень подробно описывает логику, спасибо за материал!
После фразы "вызвало смешок" - не интересно ничего от этого автора. Токсичность зло.