Вопрос очень важный и сложный. На разбиение проекта на модули могут влиять и процессы в моделируемом бизнесе, и организационная структура команды разработки (см "Закон Конвея"). И если второе можно (потенциально) изменить по потребностям, то первое нужно как минимум выяснить. Возможности внесения изменений в бизнес-процессы ограничены, как правило, но в любом случае нужно понять фактическое состояние предметной области.
В последние годы получила развитие методика Event Storming. На эту тему уже есть много видео и даже книжка [наполовину] (
https://leanpub.com/introducing_eventstorming). Ключевая идея в том, чтобы выяснить, что должно произойти до того, как мы попадём в то или иное известное состояние. Методика представляет особенный интерес в контексте микросервисов. Предложение
oxidmod также имеет к этому непосредственное отношение.
Но кроме системного уровня, нужно также разбивать на модули отдельные компоненты, чтобы можно было их помещать в голове, тестировать и развивать независимо друг от друга. Здесь Вам поможет Гексагональная архитектура (которая также называется "Порты и адаптеры"). Эта концепция поможет разделить компонент на части, реализующие бизнес-функции и (по отдельности) внешние взаимодействия: с файловой системой, с БД, с HTTP клиентами-сервисами и др.
На ещё более низком уровне советую освоить 1) отделение чистых функций от эффектов и 2) функциональную композицию - это идеи из функционального программирования. Не знаю, как с ФП в PHP, но тут практикующие программисты PHP могут подсказать.
Простой
