• RabbitMQ: что такое exchange, и где его место?

    7876010, Написал выше коммент, забыл вас тегнуть там, если что ^
  • Зачем нужно ООП?

    Ну и работайте на функциональщине, в чем проблема?

    Вы путаете Функциональное программировние и Процедурное.
  • RabbitMQ: что такое exchange, и где его место?

    я не понимаю, когда его использоваться, почему некоторые его пишут в консюмере и в продюсере? а некоторые, в т.ч. и вы, говорите, что это настраивается в брокере.

    Прежде чем писать сообщения в exchange его нужно создать(объявить) в рэббите.
    Делать это на стороне слушателя или паблишера или ещё где-то (это все может быть в разных системах) - исключительно ваш выбор.

    На уровне классов - я разделяю у себя продюсер, консумер, и всякие классы которые объявляют exchanges и т.п.
  • Зачем нужно ООП?

    Во-первых, стоит перестать бояться писать избыточный код.

    Если код избыточен его не нужно писать. Иначе должны быть цели.

    Да, ООП вынуждает описывать классы, делать конструкторы, деструкторы.

    Ну, спорно..

    например, переменные называются не i, j, k, а value, count, capacity

    А причем тут ООП?

    Когда вы пишете только процедуры, без ООП, то чем больше проект, тем сложнее понять какие функции с какими данными работают и в каком порядке.

    Согласен. Это про минусы процедур.
  • Зачем нужно ООП?

    ООП задумывалось как подход для декомпозиции кода на модули — классы.

    Вы сейчас выдаёте свое мнение за мнение автора термина. Не надо так.
    Декомпозиция кода на модули в виде классов появилась ещё в языке Симула. Он появился до введения термина ООП.
  • Как организовать архитектуру мероприятий?

    У меня возникает такая ситуация. Как отделить регистрацию от мероприятия? Пока что она принимает объект Event. Использовать интерфейс EventInterface и его реализовать?

    Event - просто DTO - если зависеть только от него и в одном месте - проблем не будет. Будет какой-то слой что зависит от ивентов и преобразует их в какие-то команды в рамках текущего контекста. Если смените общение на http - перепишете этот слой, чтобы зависел не от DTO ивента а от, условно. запроса в HTTP.

    Сквозной функционал между сервисами это плохо т.к. плодит зависимости и влечёт каскадные изменения после каждой правки. Делаете сервисы так чтобы им не было важно, Teacher там, Member или Artist.

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

    Нужно делать так, чтобы другим сервисам не важно было кто перед ними - зачем, например, в контесте "Счёт" знать должность человека и какие бывают должности?
  • Как правильно хранить данные разных пользователей в бд?

    Phoen1xx, Храните данные пользователя в json поле в вашей БД и будет вам счастье и отсутствие лишних столбцов.
    Или вынесите различающихся данные в разные таблицы БД.
  • Как хранить настройки регистрации?

    pro-dev,
    а если таких полей будет много? У нас сущность будет большая...

    Декомпозировать на несколько сущностей.
  • Правильно ли сделана связь?

    pro-dev, Я же в первом комменте написал, делать общие айдишки с uuid - абсолютно нормально.
  • Правильно ли сделана связь?

    pro-dev, А что именно?
    Нету абстрактного "правильно" - если ваши задачи решает то сойдёт.

    Делать нужно так чтобы задачи удовлетворяло, и гибким было, чтобы поменять потом если что.
    Стейт разбивать так чтобы все необходимые данные используемые в бизнес логики у агрегата были. То есть стремиться к тому чтобы одна бизнес транзакция затрагивала только один агрегат
  • Как правильно задавать свойства классам php?

    Странно, здесь же на тостере Когда использовать static метода? например, пишут что правильная работа с ооп, это как раз задавать параметры через методы, а не через конструктор.

    На Тостере много чего пишут, не стоит всему верить, точнее стоит ничему не верить, а анализировать :)
    В плане каких-то конкретных терминов часто можно узнать очень много интересных вещей загуглив первоисточник термина/историю появления(в т.ч. причины).

    Постарайтесь определить цели и понять как эти варианты помогают вам эти цели достичь. А "правильных" вариантов без заданной цели не может быть.
    В будущем в этом плане стоит смотреть на концепты Coupling/Cohesion, и почему они важны(книжки Clean Architecture, Clean Code и т.п., так же принцип Low Coupling + High Cohesion входит в паттерны GRASP).

    По теме - задавая параметры через set() методы мы:
    - Подразумеваем что все пользователи нашего класса знают какие у него параметры, и более того - что они означают. Это создаёт большую нагрузку на пользователей класса, усложняет клиентский код.
    - Позволяем в любом месте где используется класс поменять что-то внутри, и неожиданно обнаружить ошибки в других местах системы. А ещё настройки могут конфлитовать друг с другом, и одни свойства зависеть от других. Установка одного поля может требовать установки другово, и такие вещи стоит указывать на уровне интерфейса, то есть сделать вместо условных setStartDate() и setEndDate() метод setDatePeriod(DatePeriod period), даже если внутри класса это два поля.

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

    И ещё - есть разница между методами которые меняют состояние класса, и конерктно "сеттерами". Семантика важна. То что внутри класса что-то меняется нас не интересует. Нам важно лишь чтобы выполнилось то, что мы ожидаем от класса. Если мы хотим обновить статью, мы вызовем метод updateArticle(), или какой-нибудь changeTitle(), например. Если мы хотим кофе мы скажем машинке makeEspresso(), а не будем указывать количество зёрен, упростив таким образом клиентский код.
  • Как правильно задавать свойства классам php?

    Правильно - задавать свойства в конструкторе класса. А публичные поля или методы get/set это нарушение инкапсуляции.
    Класс должен полноценно работать и иметь в себе все необходимые для работы данные сразу после его создания.

    Есть исключения когда мы имитирируем структуры данных через классы-DTO(В PHP нету встроенных типов структур/data-классов), но заполнение и там должно быть через конструктор.
  • Можете объяснить зеленому что такое MVC?

    Controller бесконечно наблюдает за всей этой сценой, и, в зависимости от обстоятельств, раздает команды двум предыдущим. Например, если Model (невидимый кубик), столкнулся с другим таким кубиком, Controller исполняет на Model метод "остановиться", меняет свойство стекла на "разбитое", приказывает View дорисовать на земле осколки и так далее.

    В MVC представление само следит за обновлениями модели, контроллер только принимает пользовательский ввод и формирует команды которые отправляет модели. И конкретно этот момент плохо ложится на request/response. И в этом отличие от Model-View-Adapter
  • Можете объяснить зеленому что такое MVC?

    Вообще-то надо указывать конкретный язык приложения, поскольку реализации паттерна отличаются весьма значительно.

    Паттерн от языка не меняется, а о реализации речи не идёт.

    Косяк приведённой схемы в том что у вас контроллер формирует View и отдаёт клиенту. В оригинальном MVC представление само себя обновляет когда изменяется модель, а на вашей схеме Model-View-Adapter(где контроллер = адаптер).

    И да, MVC создано было для десктопных приложений, где по http никуда бегать не нужно, и на схему request/response MVC не ложится.
  • Что делать, если нужно получить часть данных сущности?

    Реализовывать lazy loading внутри сущности, попутно переизобретая доктрину? Ужас...
  • Что делать, если нужно получить часть данных сущности?

    Сущности - не хранилища данных. Для передачи данных в отображение используются DTO.
    Если понять этот момент, все проблемы с выборкой ненужных данных исчезают.
  • Можете объяснить зеленому что такое MVC?

    Не запаривайтесь по поводу MVC вообще, эту штуку придумали 50 лет назад для десктопных приложений. В вебе этот паттерн не используется.
    В вебе MVC обычно называют лишь разделение на модели/контроллеры/представления, а на оригинальную семантику внимания не обращают(То есть называют MVC то, что им не является), потому потихоньку от этого названия в принципе отказываются.
    MVC в вебе это обычно Model-View-Adapter.
    И пользуйтесь поиском. Тут ( MVC php на пальцах? ) годный ответ.

    Опять же
    Можете объяснить зеленому что такое MVC?

    Зелёному не нужно разбираться ни в MVC ни в MVA.