Как-то пришлось работать в проекте с DDD подходом на php, все было настолько сложно и запутанно (15 лет в разработке). вроде бы цель упростить поддержку проекта, но в итоге все становится намного сложнее. Пока думаю единственное что может быть полезным из DDD это ограниченный контекст.
Из практики скажу что tailwind.css + alpine.js это чудо позволяет создать красивые, адаптивные и быстрые интерфейсы без тонн скриптов. Большие объемы разметки легко разделяются на уровне шаблонизатора того же twig. Сперва конечно оттолкнул синтаксис и даже больше alpine.js но после реализации я приятно был удивлен результату. П.с я бэкендер
Регулярно, и стоит понимать что меняем не обязательно всю бд, а несколько таблиц. Миграции и сидеры это все выносится в инфраструктурный код и он не должен протекать в другие слои приложения.
Как основу выбирайте простой инструмент — язык, базовый фреймворк. С низкой точкой входа, чтобы проще было развивать сам инструмент и проще поддерживать конечные продукты. При этом ему необязательно быть очень популярным, достаточно быть простым. Ещё он должен развиваться
Вас не смущает тот факт что Codeigniter не особо развивается в последнее время, а его архитектура не использует принципы SOLID что способствует проблемам тестирования, масштабируемости, автодополнения в IDE?
Как-то пришлось работать в проекте с DDD подходом на php, все было настолько сложно и запутанно (15 лет в разработке). вроде бы цель упростить поддержку проекта, но в итоге все становится намного сложнее. Пока думаю единственное что может быть полезным из DDD это ограниченный контекст.
Из практики скажу что tailwind.css + alpine.js это чудо позволяет создать красивые, адаптивные и быстрые интерфейсы без тонн скриптов. Большие объемы разметки легко разделяются на уровне шаблонизатора того же twig. Сперва конечно оттолкнул синтаксис и даже больше alpine.js но после реализации я приятно был удивлен результату. П.с я бэкендер
Всегда удивляли такие подходы реализацию контакта держать вместе с контрактом
Регулярно, и стоит понимать что меняем не обязательно всю бд, а несколько таблиц. Миграции и сидеры это все выносится в инфраструктурный код и он не должен протекать в другие слои приложения.
Основной посыл репозиториев это реализовать контракт работы с базой, чтобы в любой момент заменить orm/бд на другую имплемнтацию
Вас не смущает тот факт что Codeigniter не особо развивается в последнее время, а его архитектура не использует принципы SOLID что способствует проблемам тестирования, масштабируемости, автодополнения в IDE?