О сложности домена и о провайдерах в 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 система тестирования сама по себе очень сложная и требует большего деления.

Спасибо за пояснения, надеюсь понятно объяснил)

Ответить

 

Дмитрий Елисеев

В системе тестирования всё сильно связано. В простейшем случае там нет явного смыслового разделения на какие-то поднаправления. Поэтому есть смысл её пока не разделять. Только потом если появится перекос из-за какой-то сильно разросшейся части эту часть можно будет выделить.

Ответить

Оставить комментарий

Войти | Завести аккаунт | Войти через


(никто не увидит)





Можно использовать теги <p> <ul> <li> <b> <i> <a> <pre>