Doctrine Specification Pattern или ваш реюзабельный QueryBuilder
Комментарии (2)
29 июля 2017 в 18:05
0↑
↓
Выглядит здорово, но давайте посмотрим еще раз.Чем по сути является спецификация? По сути это бизнес-правила. А раз так, то и определяться они должны в слое бизнес-логики. Но вот бизнес логике нет дела до персистент-слоя. Он не должен знать что там доктрина под капотом. Может там вообще файлики или ин-мемори хранилище. А эти спецификации тащат в бизнес-логику знания о СУБД и доктрине
php_freelancer
29 июля 2017 в 21:42
0↑
↓
У меня очень мало опыта с DDD, пока имеется только лишь громадный интерес ко всей этой теме и боль в спине от несостыковок между конечным вариантом фичи и волшебными требованиями в голове заказчика и арт директора .)Ну, а так все верно, тут Domain Layer и Persistence Layer в достаточной мере размыты. Но опять же, применять Specification Pattern уже на коллекцию сгидрированных со стоража доменов не получится в силу банального fatal out of memory error.))
Не у всех есть DDD и такой вариант со спецификациями я думаю лучше чем первый, когда дублируются эти правила в репозиториях.
Вообще, если с точки зрения DDD это не какой-то банальный кейс, я бы очень хотел услышать ваше мнение, как и что Вы бы применили для решения подобных проблем.
