Последовательность вызовов, если мы говорим о "Controller -> Service -> Repository" не претерпела кардинальных изменений. Основные изменения были сделаны в архитектуре проекта, которые описываются в части 2 данного цикла статей, а так же изменения обязанности классов и их конструирования (пример с валидацией). Данная часть отражает наложение тактических шаблонов DDD на наш код и описывает ответственность за работу с ошибками в каждом контексте.
Как происходит общение между контекстами? Если, к примеру, нужно получить в контексте Баннер список товаров из контекста Рекомендации?
Практика проекта - использование сервисов уровня приложения в необходимом контексте. В примере из вопроса - мы бы воспользовались сервисом Рекомендации в сервисе Баннеров.
Если фреймворк предоставляет библиотеку для работы с чем либо, как ее протягиваете в доменный слой?
Сейчас у нас в доменном слое в основном аннотации для поднятия бинов. Если есть необходимость в сторонне библиотеке в домене - оборачиваем её в наше понятие и используем. Интересен был бы пример библиотеки.
сначала говорится о 14ти методах, а потом в следующем же предложении - о единственном
Соглашусь, что сам абзац мог показаться несколько сумбурным.
Постараюсь внести ясности.
В данном абзаце (Проблема №3) речь идёт о том, что сам интерфейс хранилища, который используют два несвязанных между собой сервиса уже содержит много методов, что само по себе нарушает принцип "I", но так же и содержин единый (в абзаце слово "единственный" может сбивать с толку) метод для использования обоими сервисами и единый объект, который эти сервисы могут использовать в разных сценариях.
Это не нарушение принципа Open-Closed?
Нарушение. Часто на практике встречаются подходы, когда в угоду быстроты разработки просто меняют обязательность полей. И как раз опасность такой замены хотелось бы избежать, так как зачастую, изменение обязательности происходит в рамках контекста, но не всего приложения.
Рассчитываю, что предложенные решения в следующих частях помогут прояснить заявленные проблемы :)
Да, это один из плюсов. Достаточно подробно плюсы этого подхода описываются в книге "Effective Java" Блоха.
На вскидку могу вспомнить:
Возможность описания в контракте негативного результата
Возможность детального и понятного наименования метода
Возможность соблюдения инвариантов
Последовательность вызовов, если мы говорим о "Controller -> Service -> Repository" не претерпела кардинальных изменений. Основные изменения были сделаны в архитектуре проекта, которые описываются в части 2 данного цикла статей, а так же изменения обязанности классов и их конструирования (пример с валидацией). Данная часть отражает наложение тактических шаблонов DDD на наш код и описывает ответственность за работу с ошибками в каждом контексте.
Каждая из проверок реализует свой интерфейс на уровне домена, после чего используется в необходимых сервисах, например
Практика проекта - использование сервисов уровня приложения в необходимом контексте. В примере из вопроса - мы бы воспользовались сервисом Рекомендации в сервисе Баннеров.
Сейчас у нас в доменном слое в основном аннотации для поднятия бинов. Если есть необходимость в сторонне библиотеке в домене - оборачиваем её в наше понятие и используем. Интересен был бы пример библиотеки.
Соглашусь, что сам абзац мог показаться несколько сумбурным.
Постараюсь внести ясности.
В данном абзаце (Проблема №3) речь идёт о том, что сам интерфейс хранилища, который используют два несвязанных между собой сервиса уже содержит много методов, что само по себе нарушает принцип "I", но так же и содержин единый (в абзаце слово "единственный" может сбивать с толку) метод для использования обоими сервисами и единый объект, который эти сервисы могут использовать в разных сценариях.
Нарушение. Часто на практике встречаются подходы, когда в угоду быстроты разработки просто меняют обязательность полей. И как раз опасность такой замены хотелось бы избежать, так как зачастую, изменение обязательности происходит в рамках контекста, но не всего приложения.
Рассчитываю, что предложенные решения в следующих частях помогут прояснить заявленные проблемы :)