О сложности домена и о провайдерах в PHP
Провели ленивый импровизированный стрим на общеполезные темы. Чем неудобен в разработке процедурный код и код без разделения. Какие сложности предметной области обнаруживаются при анализе бизнеса. Про сходства и различия фреймворков. Про использование интерфейсов и классов провайдеров для конфигурирования приложения и для организации гибкой модульности:
Для удобства просмотра можете поставить скорость 1.5 в настройках проигрывания.
- 00:01:31 - Почему фреймворки с объектами, а не процедуры
- 00:05:22 - Сложность тестирования
- 00:07:57 - Пример с импортом
- 00:11:58 - Общий вход и выход
- 00:15:51 - Классы - это не всегда ООП
- 00:18:48 - Об именовании классов
- 00:22:23 - Анализ предметной области
- 00:24:28 - Пример открытия кафе
- 00:28:36 - Что если сначала не понимаем бизнес
- 00:31:47 - Гибкая разработка
- 00:34:19 - Сложность предметной области
- 00:39:56 - Что даёт разделение на подобласти
- 00:42:55 - Пример службы такси
- 00:46:29 - Как запустить MVP
- 00:48:14 - Нужна ли сложность
- 00:53:09 - Общий принцип фреймворков
- 01:02:05 - Различия реализаций фреймворков
- 01:06:41 - Почему у фреймворков всё своё
- 01:09:40 - Библиотека Guzzle
- 01:10:58 - Как хранить конфигурацию
- 01:21:01 - Провайдеры конфигурации
- 01:28:37 - Провайдеры для модулей
Если есть желание провести похожую публичную или разбор кода (который вы сможете показать без ограничений NDA), то пишите мне. Если тема интересная, то запишем скринкаст. А чтобы не пропустить следующую статью о практиках внедрения зависимостей в сервисы подпишитесь на почту или на канал @elisdnru в Telegram.
МаксимЗдравствуйте, Дмитрий)
Можете рассказать как вы поступаете с разделением большого проекта на контексты?
Как вы сказали, то есть ваш проект называется site(domain), а поддоменами (subdomain) являются: Auth, Blog, Payment и так далее.
Допустим у нас есть проект по образованию. У этого проекта есть курсы, система тестирования и т д. Система тестирования на столько сложная, что просто сделать всё в одну папку TestingSystem не будет хорошо. Так как система состоит из нескольких логических этапов для разделения ещё на небольшие части: разработка тестов, прохождение тестирования и оценка.
Как в этом случае лучше разделять подобные вещи, если subdomain система тестирования сама по себе очень сложная и требует большего деления.
Спасибо за пояснения, надеюсь понятно объяснил)
Дмитрий ЕлисеевВ системе тестирования всё сильно связано. В простейшем случае там нет явного смыслового разделения на какие-то поднаправления. Поэтому есть смысл её пока не разделять. Только потом если появится перекос из-за какой-то сильно разросшейся части эту часть можно будет выделить.