нет бизнес логики , по большей части инфраструктурная, сбор данных из различных источников по api, ui фильтры, визуализация данных в виде графиков, выгрузка в excel, csv, pdf , сохраняем и обновляем статистику по конкретной рекламной кампании ( JPA), стабильная часть: интерфейс "приложения|домена" (список кампаний/список рекламных площадок/рекламная площадка/статистика), концептуально сущности это отчеты(статистика), получается есть адаптеры к каждому внешнему api - это слой приложения ? каждый адаптер реализует интерфейс заданный на слое ("домена|?") ? все адаптеры должны соответствовать единому интерфейсу, итог: контроллер делегирует вызов (например: получить список рекламных площадок) -> @Service сервису[X], сервис[X] ->делегирует вызов -> адаптеру[Y] -> отдает DTO . вопросы: 1) нужно ли выделять слой домена, и куда поместить интерфейсы ? 2) нужны ли сервисы в таком случае или из контроллера можно вызывать методы конкретного адаптера 3) какие паттерны тут уместны, как правильно структуировать приложение ?
2) сервис будет прослойкой между адаптером и контроллером что зачастую удобно. У тебя контроллер будет вызвать определенные методы которые будут делегировать адаптер Когда будет появляться бизнес логика в целом полезно Это чисто мое мнение джунчика
1) по идеи грамотно будет раскидать интерфейсы в слое домена, в целом будет удобнее дальнейшее писать
Обсуждают сегодня