Роман

# The optional transport(5) table specifies a mapping from
# email addresses to message delivery transports and next-
# hop destinations. Message delivery transports such as
# local or smtp are defined in the master.cf file, and next-
# hop destinations are typically hosts or domain names. The
# table is searched by the trivial-rewrite(8) daemon.
#

apupkin@example.com mail01.example.com
vtaburetkina@example.com mail02.example.com

В PHP отсутствует Double Dispatching и перегрузка методов

class Foo {
    // ...
    public function makeSomeStuff(Bar $bar)
    {
         $bar->doStuff($this->someData); // double dispatch!
    }
}

class Foo {
    public function foo() {}
}

class Bar extends Foo {
    public function foo() {} // перегружен!
}

и в ответ на отличающуюся от базового класса/интерфейса сигнатуру он вывалится с ошибкой

Но решить проблему как-то нужно

Однако каждый из хендлеров может не работать с конкретной реализацией сервиса.

$('.view').click(function(){
   var $el = $(this),
       type = $el.data('view-type');

   $('.view.view--active').removeClass('view--active');
   $el.addClass('view--active');

   $('.maicol-catalog').removeClass('catalog-view1 catalog-view2 catalog-view3');
   $('.maicol-catalog').addClass('catalog-view' + type);
});

Как хранить бизнес-логику чтобы модели не превратились в монстров из десятков тысяч строк?

Читал про Command Bus где, если правильно понял, на каждое действие в системе – свой класс?

Как их организуете (их тогда будут сотни)?

Есть ли смысл выносить каждую доменную модель в модуль/микросервис, хранить всю связанную логику где-то там внутри, а с остальными общаться по внешнему API?

За ответы в клиентскую часть – отдельный сервис-фронтенд?

Каков оверхед?

Используют ли такое на практике?

Какие подводные камни?

Как не превратить кидание/получение событий типа PostBeforeEdit/PostBeforeEditHandler в "callback hell"?

ACL Где храните указанную логику?

Какие структуры для описанного выше – best practice?

В моём понимании это выглядит как куча трёхмерных кубов доступа "crud – group – entity – field", как это сделать более плоским пока только одна идея – делать кучу таблиц many-to-many.

Версионирование. Как вы версионируете подобные проекты?

А если нужна "N-1" рабочая версия на продакшене?

Есть ли смысл разделять версии в рамках единой кодовой базы проекта и как (неймспейсы, конфиг, модуль, что-то ещё)?

И, самое главное – как всё это совместить?

• РУКОВОДСТВУЙТЕСЬ ЗДРАВЫМ СМЫСЛОМ
  
• Принимаете жесткие соглашения по правилам написания кода, например такие
  
• Постарайтесь убедить бизнес в том, что без покрытия кода автотестами будет дороже, нестабильней и дольше. + Пишите тесты. Если объем тестов в 4 раза больше кода, который они тестируют - это норм. У меня бывали случаи, когда для критичного функционала тестов было в ~16 раз больше, чем кода.
  
• Жесткие, обязательные кодревью.
  
• Если задача крупная - декомпозируйте ее.
  
• Технический долг - возвращайте обязательно И как можно скорее.
  
• Перед тем как писать код для работы с внешним сервисом - имеет смысл написать его эмулятор.
  
• Спешите только в случае серьезных проблем на проде)). Фичи "на вчера" отличаются от фич "на потом" только приоритетом выполнения, более ничем.
  

Как их организуете (их тогда будут сотни)?

Есть ли смысл выносить каждую доменную модель в модуль/микросервис

Раньше для дополнительных действий мне достаточно было использовать что-то вроде beforeUpdate/afterCreate модели.

Как не превратить кидание/получение событий типа PostBeforeEdit/PostBeforeEditHandler в "callback hell"?

ACL. Где храните указанную логику?

Как вы версионируете подобные проекты? А если нужна "N-1" рабочая версия на продакшене?

На какие проекты (точнее, на код) можете посоветовать посмотреть для лучшего понимания? Ссылки на репозитории?