Антон Шаманов

Модуль платежей - занимается платежами (как подсказывает капитан Очевидность), никаким хранением данных он заниматься не должен (логи разве что вести). Если речь о микросервисной структуре, то после платежа информация о нем рассылается через вебхуки всем подписчикам т.е. магазину и, например, какому-то бух.модулю

https://ru.wikipedia.org/wiki/Design_Patterns

Рассматриваем только домен без баз данных

и как ты собираешься данные хранить?

Я правильно понял что планета должна иметь +-10 параметров для конструктора?

зависит от того как хранить эти данные: например, если это cвязанные ActiveRecord/ORM модели, то достаточно передать id планеты.

Oбъекты должны создаваться внутри класса только если объекты данного класса нигде больше не используются.
В остальных случаях используются Factory/Builder классы и DI контейнеры.

Для начала бы хоть объяснил что именно ты парсишь.

А если понадобится писать не в базу, а в файл, писать Parser2?

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

твой Оbj это DTO объект передающий данные загруженные ОD из базы в Widget/View для отображения

ну твой класс сотрудника и его наследники могут быть не публичными т.ч. будут доступны только внутри пакета и наследников.

Является ли плохой практикой создавать интерфейс для DTO, чтобы уйти от конкретных реализаций с их применением?

эээ... а когда создание интерфейсов вообще может оказаться плохой практикой? ну если не брать совсем идиотские примеры.. DTO - это не аналог stdClass в PHP, класс может и должен инкапсулировать данные, доступ осуществляется через методы. Интерфейс декларирует методы для работы с "required" "свойствами" класса.

делаешь проверки отдельными классами, обходишь циклом массив проверок - банально..

а ооп то тут где?

возьми DB/ORM и Auth пакеты из доступного тебе фреймворка и сделай на их базе приложение. Писать придется в половину меньше, в том числе тестов.

можешь использовать __invoke()

public function __invoke($method)
{
      if (!method_exists($this, $method)) {
            throw new BadMethodCallException($method);
      }
      return [$this, $method]();
}

ну и испльзование: $instance = new Test(); $instance($method);

откат с какого метода до какого? проще всего хранить собственный клон и в случае отката вернуть его.

обернуть объекты в прокси или регистрировать обработчики событий

class Control {
  #position = 0;
  on(eventName, listener) {
     if (typeof this['on' + eventName] !== 'function') {
         throw new Error('Event "' + eventName + '" not exists');
     }
     this.addEventListener(eventName, listener);
  }
  fire(eventName) {
       let event = new CustomEvent(eventName, {detail: this});
       return this.dispatchEvent(event);
  }
  onmove() {
    this.#position += 10;
    return this.fire('move'));
  }
}

не будет, но лучше использовать абстрактную фабрику
p.s. new зарезервировано php и не может быть именем метода

Не надо так делать, реализуй шаблон Strategy

БД есть очень много разные данные для каждой сделать не возможно!

не верно ты дядь федор этот бутерброд жрешь - надо не магией баловаться, а написать "scaffold" - генератор классов-моделей на основе данных таблиц. смотри gii в Yii2

поздравляю, ты открыл для себя шаблон проектирования фасад

реализуй шаблон strategy + decorator