Нужно видеть реальную задачу. Не понятно, что вы хотите сделать. В любом случае, данные в объекте храниться не должны, для данных есть хранилища (база/файл/удаленный сервис и т.д.). Из данных собирают объект или вложенную иерархию объектов (агрегат). Скорее всего, то что вы хотите хранить в $this->data можно разложить на дочерние объекты, которые будут жить внутри класса Class.
Нет. REST не устанавливает никаких требований к контроллерам. Он предъявляет требования к формату запроса/ответа, но не накладывает никаких ограничений на возвращаемые данные из контроллера. Что конкретно по вашему в этом подходе противоречит рест?
Лучше скачайте/купите Implementing domain-driven design, вот эту красную книжечку https://vaughnvernon.co/?page_id=168 Это практика, не теория. Когда я изучал тему, прочитал изначально, только раздел про Entity вдохновился и пошел делать эти сущности. Затем возник вопрос, а как сделать доменный объект из нескольких Entity и пошел читать про Aggregate. Затем, как это всё сохранить и прочитал про Repository. В итоге, со временем по кускам прочитал почти всю книгу. Любую тех. литературу нужно так читать:
1. Делаем проект
2. Возникает вопрос
3. Ищем решение в книге
4. Возвращаемся в пункт 1
Статьи я читал как дополнение, просто гуглил, куча разных блогов/сайтов/stackowerflow и прочего. Но это все разрознено по какому-то конкретному небольшому вопросу, а так чтобы ввиде цикла статей о проектировании доменной модели и многоуровневой архитекруты не встречал.
Но если хотите, то https://lostechies.com/jimmybogard/category/domain...
Но лучше пишите приложение, ищите решение в книге и гуглите, в большинстве случаев гугл вас все равно будет отправлять на какие-то конкретные статьи из этого блога, там много по теме DDD. Это продуктивнее и быстрее, чем выискивать какие-то конкретные статьи.
Также посмотрите тестовое приложения на DDD https://github.com/citerus/dddsample-core/tree/mas... и примерно поймете, как нужно организовывать код, что куда складывать. Пример на Java, но зная PHP можно примерно понять, что там и как.
В любом случае, вы будете делать и переделывать сделанное, так как ваши знания будут постепенно расширяться. Сразу круто не получается ни у кого. Даже сейчас, если вы не знаете ничего, всё равно пишите код. Вам нужно создать ваш первый доменный объект? Отлично, откройте упомянутую выше книгу и прочитайте раздел про Entity. И сделайте её. Для этого не нужно читать всю книгу.
olijen: Отказываться не обязательно. Но и использовать смысла мало. Репозиторий всё равно должен возвращать доменный объект, а не AR модель, так на кой черт она вам нужна? Из данных создать AR модель, затем из AR модели создать доменный объект? Смысла ноль, лишнее потребление ресурсов, излишняя зависимость инфраструктуры от фреймворка. Захотите откатиться с этого фреймворка - будете переписывать все репозитории, оно вам надо? Сделайте своё небольшое решение, которое будет напрямую заполнять доменный объект данными из базы и раскладывать доменный объект в данные для сохранения в базу. Если вам не принципиально хранить данные в реляционном виде в куче плоских таблиц, то не очень сложно написать реализацию для хранения их как иерархических структур в виде JSON объектов. Вон Вернон пишет как это делать в PostgreSQL. В MySQL естественно плюс/минус тоже самое. Если принципиально, то попробуйте прикруть, хотя бы Doctrine, так как свой костыль будет написать уже довольно сложно, а собирать/разбирать доменные объекты руками, это долго. Но я бы не терял на всё это время, когда можно сделать гораздо удобнее, чем подход из 70ых годов прошлого века.
Оптимус Пьян: мок-объект - это фальшивый объект, который имитирует поведение реального объекта. Мокать методы, это значит, создать мок-объект с нужным набором методов для теста, методам можно сказать, чтобы они возвращали заранее заготовленные значения и прочее.
Например, у вас есть метод объекта, на который вы хотите написать тест. Но этот метод внутри себя вызывает метод другого объекта например для работы с базой данных. Тогда вы перед тестом можете создать мок-объект имитирующий объект для работы с базой данных, указать, какие значения должны возвращаться из методов мок-объекта и прочие настройки. Теперь ваш метод, на который вы пишите тест будет внутри себя вызывать мок объект вместо реального объекта для работы с базой данных. Что вы получили? Вы получили возможность проверить тестируемый метод без необходимости реального обращения к базе данных.
Оптимус Пьян: вы когда хотите написать код метода, понимаете что он должен делать и какая у него должна быть сигнатура? Просто представьте, что этот метод уже есть, вы знаете какие агрументы он должен принимать и что возвращать. Теперь просто вызовите этот несуществующий метод в тесте, сравните результат работы с ожидаемым. Тест естественно не пройдет. Теперь подумайте какими внутренностями нашпиговать метод, чтобы тест проходил.
MaxKorz: это уже ваше предположение, что метод будет одинаков. Моя задача показать, что такое полиморфизм подтипов на примере автора. Поэтому конкретная реализация классов не имеет никакого значения.
Полиморфизм = многообразный. Это значит, что вы не должны делать N правок. Каждая конкретная реализация интерфейса должна иметь своё собственное отличное от других поведение. Именно это я пытался донести. Если поведение всегда одинаково, то очевидно, что полиморфизм не нужен вообще. Собственно это нужно понимать, т.к. вопрос о полиморфизме, а не об архитектуре приложения.
я бы сделал так sandbox.onlinephpfunctions.com/code/3385d3ecb1d405...
Нет никакого смысла иметь абстрактный класс, без абстрактных методов.
Оптимус Пьян: основная задача ORM это конвертировать данные из базы в объекты и наборот объекты в данные. Нужно, для того, чтобы работать с объектами, а не возиться с сырыми данными.
vjjvr: нужно просто помнить как они образуются, чтобы в тексте различать где субъект выполняет действие над объектом, а где объект претерпевает действие.
Человек построил здание - активный залог.
Здание построенно человеком - пассивный залог.
Запомнить, что в группе simple пассивный залог образуется как to be + past participle. И всё, больше ничего не нужно. Это просто очень сильно поможет новичку понимать предложения на английском. Потому что иначе бывает, что вроде все слова знаешь, но суть не понятна. Со временем форма пассивного залога примелькается и мозг даже начнет воспринимать предложения в пассивном залоге из других групп такие как to be + being + past participle в группе continuous и to have + been + past participle группе perfect, хотя человек их мог даже специально вообще не изучать, просто интуиция подскажет.
Что будет, если в результате сбоя данные в mysql изменятся, а в ES нет? Например упало приложение до апдейта ES, но после mysql. Со временем, будет расхождение в данных.
Я бы лучше сделал синхронизацию по крону. Можно просто добавить поле updated_at и при каждом insert/update писать туда таймштамп. Скрипт раз в N времени приходит, забирает новые данные и раскладывает в ES. Можно также посмотреть готовые решения https://www.elastic.co/guide/en/logstash/master/pl...
Поиск будет отдавать немного устаревшие данные, но возможно это не критично и менеджерам можно объяснить, что мы тоже тут не боги.
Косяки бывают, но это ошибка, когда документация расходится с кодом. Соответственно , когда кто-то сделает репорт, то разработчики выпустят фикс, который исправляет документацию или код.
Но со статьями иначе, по мимо ошибок, там может быть личное заблуждение автора или в вашем случае - предпочтение, т.е. в отличие от документации статья имеет место субъективному мнению. Поэтому и не надежный источник.
Напишите какую вы задачу решаете.