dmitriy

в вашем случае по типам классов: Helpers, Configs, Exceptions,
Классы которые носят универсальный характер и не связанны с приложением, как правило в /vendor/{your_company}/{project}
как упомянули выше

как правило Repository - уровень инфраструктуры а не домена, с доменом они связанны интерфейсами.
например доменная сущность (по сути это BLL):
Domains/User/User
Domains/UserCollection
Domains/User/RepositoryInterface (возвращает User, UserCollection)

Инфраструктура:
Infrastructure/User/Repository (реализует RepositoryInterface, работает с бд, использует DAL, mapping)

ну и Application
контроллеры, GUI , views

1. создание прототипа системы с архитектурой решающей текущие проблемы
2. переезд на новую архитектуру с использованием адаптеров, паттернов позволяющих адаптировать старый функционал под новый.
3. Написание нового функционала в новом стиле, старого функционала переработка через рефакторинг,(выкидываем внутрянку без изменения внешнего поведения)

Bitrix24

А почему бы работу со связями не возложить на ORM?

Мы используем docker + docker-compose только для веб-окружения, вместе с сайтом идет docker-compose конфиг, который мы используем для поднятия проекта. Этот же конфиг используется на промежуточном сервере для поднятие окружения для тестов.
Эту конфигурацию используем как на Linux так и на windows + docker.
В окружении несколько контейнеров, nginx, apache, tools, mysql. Каждый контейнер имеет свою версию, свои приложения, для разработки используем tools где есть все необходимые инструменты: composer, xdebug и тд.

не делается это в шаблонах

Одна голова и пара рук

1. спроектировать сущности
2. создать документацию на swagger
3. реализовать серверную php часть апи, (sawgger editor позволяет создать каркас)

это тот случай когда adapter db не использует psr logger interface и не использует SOLID

https://fractal.thephpleague.com
позволяет делать include связанных сущностей например
/orders?include=client

но как правило это делается для связей один к одному, многие к одному
для связи один ко многим, обычно делаю /orders/{order_id}/statuses
если statuses жестко зависит от order не существует без него.

Redmine, trello, asana хороши для управления задачами проектами, но не хватает инструмента по управлению финансами, документами, контрагентами, в итоге написали свое.

1. Установите develop основной веткой, в настройках репозитория
2. Используйте Soource Tree с gitflow схемой из коробки, будете работать через меню операций: начать исправление - завершить исправление, начать тематическую ветку - завершить тематическую ветку, и тд. Все проверки и рутинные операции возьмет на себя gitflow.

1.

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

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

public function printCustomerFirstname(Payment $payment)
{
    if ($payment->getCustomer()) {
        echo $payment->getCustomer()->getFirstname();
    }
}

echo в методе в 2018 - неприлично

3. Проверка решается выбросом исключения

public function getCustomerFirstname(): string
{
    if(!$this->getCustomer()){
       throw new \Exceptions\CustomerNotFound;
    }
    return $this->getCustomer()->getFirstname();
}

try{
$customerName = $payment->getCustomerFirstname();
}
catch( \Exceptions\CustomerNotFound $ex){
$customerName = null;
}

Как вариант сформировать csv а в нужный формат перегнать утилитой например libraoffice

$route['(:num)'] = 'main/view/$1';
$route['(:any)'] = 'pages/view/$1';

должны быть в самом начале