Да там есть и ленивая и жадная загрузка. Не в этом проблема.

Другими словами, как мне получить объекты акций, которые сейчас я получаю SQL запросм (можно даже хитрее):

SELECT * FROM `promotions` 
    WHERE `id` IN (тут список полученных ранее `id_promotion`) 
        AND `date_start` >= NOW() AND `date_end` <= NOW() 

Если они должны выбираться отдельно, а не как связанные с конкретным продуктом. Вытаскивать их всех, а потом искать среди них нужные? А если их очень много? Выбирать запросом, DDD не позволяет, я говорил уже. :(
Или я чего то не понимаю, или Active Record использовать в DDD можно только через задницу. О чем собственно и говорилось.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

twin, используй репозиторий

Использовать не проблема. Проблема создать. О чем я и спрашиваю. Мне все возможные варианты поместить в репозиторий? Какой тогда смысл в Active Record? И не слишком ли это жирно будет?

Вот вариант с CQRS я даже рассматривать не хочу. Потому что на кой мне нужно два параллельных хранилища, да еще и принцип испортится. Я же не просто магазин сляпать хочу. Он бы работал давно уже. Я хочу по полной программе использовать AR.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Конфликтует, и еще как. Репозиторий, это хранилище готовых и самодостаточных объектов. AR - это инструмент для изготовления объектов, чаще всего на основе реляционных хранилищ.

Вот я и хочу понять, как этот конфликт нивелировать с минимальными потерями. Пока получается плохо.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

twin, я тем там не вижу того что ты говоришь. Ты неправильно интерпретируешь паттерн репозиторий

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Ну может мы с разных сторон смотрим. Вот из твоей ссылки:

Нашел что-то более менее подходящее. Так называемая луковая или гексагональная архитектура. Они очень похожи, я пока не выбрал. Но принцип обоих вполне подходит для "правильного" использования AR в ООП.

Все новое, хорошо забытое старое. Я мельком рассматривал их, когда сочинял систему мидлваров для фреймворка. И сейчас, видимо интуитивно, я сделал примерно тоже самое. Те же кольца, так же запрос идет снаружи внутрь и обратно.

В двух словах (см. картинку). Внутренность розового цвета, это и есть та самая, преславутая доменная модель. Её можно вполне безболезненно строить по всем правилам DDD, нужно только абстрагироваться от механизмов, и рассуждать исключительно с точки зрения объектов. Нет там ничего, кроме объектов. Ни классов, ни функций, ни базы данных. Только сущности, VO и DTO. Ну может совсем чуток сервисов, хотя лучше без них. Там нужно рассматривать только взаимодействия и общение.

И совершенно не важно, откуда и как берутся эти объекты. Если исползуется AR и РСУБД, ничего страшного в этом нет. Больше скажу (тут я вынужден не согласиться с многоуважаемым Сантехником), ничего страшного нет даже в использовании элементов DAO, если делать это в разумных пределах. Важен результат - в итоге должны появляться объекты, и общаться между собой должны на уровне объектов.

На моем примере. Да, использовался SQL запрос, но в итоге не появились какие то отдельные данные, а родилась связь объектов, по сути агрегат (от слова агрегация). Данные из этого агрегата получит по цепочке приложение, а потом уже фреймворк для использования во вьюшках или для каких то иных целей.

Если сравнивать с реальным миром, объекты в доменной модели (внутреннем слое), это актеры театра. Им раздали сценарий (DDD), по которому они знают, что когда и с кем делать.

Второй слой - зеленый, это приложение. Это сцена с реквизитом и суфлерской будкой. Вот тут уже строится логика поведений согласно сценарию.

Ну а всякие гримерки, раздевалка для зрителей, партер и буфет - это третий слой - фреймворк или инфраструктура. Он обеспечивает комфорт для зрителей и актеров.

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

Резюмируя самое главное. Не важно, каким образом генерируются и сохраняются объекты. Важно, что бы логика строилась на их взаимодействиях, а не на линейной обработке полученных от них данных. Тогда не особо важно, AR используется, DataMapper или черт в табакерке.

Вопросов конечно много осталось, но направление кажется я все же выбрал.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

На повестке дня теперь стоит вопрос анемичности моделей. По такой схеме велик соблазн всю бизнес-логику разместить в слое приложения. Но Фаулер говорит - аяаяй. Хотя многим нравится. Вот и дядя Боб что то говорил про недопустимость логики в AR.

Но я нкогда слепо не молился на паттерны, можно и немного нарушить SOLID. Тем более, что Фаулер мне импонирует больше.

И вот теперь очередной вопрос встал. Прокинуть калькулятор скидок в класс товара, или пусть висит в слое приложения?

Кстати, а где вообще распологать сами классы AR? По сути это же билдеры (или фабрики, хотя мне кажется тут это название паттерна не подходит). Само напрашивается сделать еще один слой между доменной моделью и приложением. Сделать его пограничным и в нем разместить доменную логику. Вроде логично получается...

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Кстати, тут нужно уточнить. Я, кроме той цитаты, с удивлением увидел у Мартина еще вот это:

twin, я сваливаю, ты какой-то дубовый.

Сам создаешь проблемы, сам решаешь, просишь советов, но советов не слушаешь, умудряешься интерпретировать простые и понятные вещи, какой-то безумной "теологией". Ну и плюс, спустился до уровня адептов "луковой архитектуры", которые обычную практику разделения кода на ответственности(слои) называли "луковой" или "гексагональной". Я все, кончился.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

А я что, держал кого то? Кончился, не успев начаться.