Хорошая статья! Но не всегда думаю стоит разносить по отдельным модулям (если это не оправдвно только). Сам пару лет назад попробовал гексагоналку и теперь практически любой новый проект пишу на ней, после заходишь через год в проект и сразу же видишь что где и как работает ! Ну да немного больше кода, маппинг между контроллером в домен, из домена в чущность - и обратно. Но эти затраты очень "окупаются" после! К тому же контроллеры чистые (в три строки), логика сразу понятна и отделена в 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 и подобных ?
Очень хороший и полезный материал!
Что касается "вопросов котрые возникли у экспертов сообщества" - имеют место быть, да, но личное мнение, что они дополнительные, назову их моментами, ньюансами, и конкретной спецификой, которых впрочем может гораздо больше (из перечисленых).
Статья итак очень подробно описывает логику, спасибо за материал!
После фразы "вызвало смешок" - не интересно ничего от этого автора. Токсичность зло.