Yii Framework

Всем добра!
Развиваюсь в сторону DDD, есть интересный для меня вопрос.
Ситуация(для примера):
- есть доменная сущность House
- в этой сущности есть метод getSummCount, результат метода - число, но формируется оно очень тяжеловесным SQL запросом.

Сейчас, на этапе разработки, я запилил SQL-запрос прямо в доменную сущность. Плюсы - работает. Минусы - не тестируется, инфраструктурная логика в домене. Понимание того, что в домене не должно быть репозитарного кода - имеется.

Итак.
Первая идея - реализация в сервисе с учётом переданного репозитория, например HouseService->findById($id), где ищем по id, считаем summCount, и отдаём в конструктор return new House (...., $summCount). Минусы - запрос тяжелый, и нужен совсем не везде.
Вторая идея - в нужном контроллере, после получения сущности, делать метод HouseService->calcSummCount, который будет делать set для нашего экземпляра в переменную House->summCount

Как мне сделать эту цифру "по необходимости", к чему стремиться?

Alert230 писал(а): ↑2019.01.23, 06:38
Минусы - не тестируется

А почему не тестируется? Фикстуры или haveInDatabase() (codeception в помошь).


А в остальном (без этого метода) сущность изолирована от базы (исп. DataMapper)? Если нет я бы оставил так так есть и тестировал бы вместе с базой.

Думаю вторая идея в самый раз. Добавил в сущность дполнительное поле sum. По мере необходимости через сервис расчитал сумму и сохранил в сущности. И дальше использовал только это поле.

Вариант - в сервисе запилить метод, который будет считать и возвращать это значение (либо вообще отдельный сервис с единственной функцией - HouseSummCountCalcService, что то в этом роде). Если запрос действительно тяжелый и редко нужен - не нужно в findById его вычислять. Ну и появляется еще дополнительный вопрос - действительно ли место в вашей доменной сущности методу getSummCount(). Я для таких специфических вещей люблю сервисы использовать.

Я бы тоже посмотрел в сторону отдельного сервиса (и репозитория для него). Особенно если метод специфичен для, например, отчёта.

samdark писал(а): ↑2019.01.23, 19:30 Я бы тоже посмотрел в сторону отдельного сервиса (и репозитория для него). Особенно если метод специфичен для, например, отчёта.

идея логична и понятна.
У меня вытекающий абстрактный вопрос. А есть какое то ограничение на передачу в домен напрямую репозитория/сервиса? Чтобы получать данные по декоратору. Ест-но исходя из философии DDD. Или все сущности нужно формировать внутри action ?

По-хорошему, должна быть граница. На этой границе всё специфичное для хранилища должно очищаться и становиться доменными DTO/Entity и наоборот.