О сложности домена и о провайдерах в 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>