Re: 2amigos/yii2-usuario
Добавлено: 2017.09.13, 06:26
Мой ответ в основном не про эти модули, а про осторожность, которую стоит проявлять, когда начинаешь заниматься "архитектурой"
Да, в usuario с интерфейсами и паттернами явный перебор. Архитектура для архитектуры, а не для решения задачи.
Зачем выделены мегаобщие интерфейсы типа StrategyInterface? Заменить любую стратегию на любую другую? Декорировать все и всем? Абсурд.
Пытаются создать возможность заменить что угодно на что угодно, создать абсолютную гибкость. Это ошибка. Нельзя предусмотреть все и вся наперед. Проблема известна как premature generalization. По мне нужно при проектировании определить что конкретно может измениться в будущем и оставить швы под это. Или добавлять швы, выделяя интерфейсы по мере появления необходимости в других реализациях/декорировании. Изолироваться от всего и вся создавая интерфейсы сразу и для всего - игрушки.
Согласен с BrusSENS, нужны в общем-то библиотеки, а не модули. Архитектурные решения должны приниматься исходя из бизнес-задач. Универсальные модули - миф. Разобьются о первое кастомное бизнес-требование. От них больше вреда, чем пользы в нетиповом проекте. Для типовых сайтов, да могут подойти. Но там разговоры про архитектуру не имеют смысла. На CMS стандартные магазины хорошо делаются.
О "stateless" сервисах и DiC
---------------------------------------
Будьте осторожны! В последнее время пошла мода как можно больше классов делать т.н. "stateless" и пихать все в контейнеры. Мода пришла из Java в Symfony, сейчас разносится по многим фреймворкам, в т.ч. yii. Это порочная практика. Stateless объектов не должно существовать. Иначе это не объекты, а функции. На самом деле в контейнер можно и нужно засовывать не так много. Например репозитории - они инкапсулируют соединение с БД и название таблицы/таблиц. Это их состояние. Они не stateless. Такие классы разработаны правильно и их можно пихать к контейнер. Моделируют шлюз к ханилищу. Что дают - шов для замены слоя работы с бд.
Пример-антагонист: PasswordChangerService. Инкапсулирует только UserRepository. У него есть метод execute который вытаскивает юзера и меняет ему пароль. Такие "stateless" сервисы возвращают нас к процедурному программированию. Полученный сервис это процедура, а сущность юзера это данные. Это не объекты, а функции и структуры данных, написанные в виде классов. ООП должно моделировать объекты реального мира. PasswordChangerService ничего не моделирует. Это алгоритм, а не объект.
Больно видедь конфигурацию контейнеров с сотнями инжекций, из которых реально понадобятся 2-3. а времени на разбор такого кода уйдет в 2-3 раза больше.
Про DDD и повальную моду на него
--------------------------------------------------
Люди кидаются в DDD без изучения ООП и воспринимают его с тактической стороны. Типа надо создавать сущности, сервисы, шины, события и тогда у нас будет DDD и это хорошо. Не будет. DDD это в основном про аналитическое проектирование, как разговаривать с менеджментом, как писать юзкейсы (на бумаге) а не "как назвать классы". Начинать лучше с книг по объектно-ориентированному анализу и проектированию. Вернон после этого будет читаться совсем по-другому. Хороший объектно-ориентированный код можно получить и вовсе без DDD, DiC и шин (польза шин вообще сомнительна).
Про шины
--------------
Реальных юзкейсов для шин вообще не очень много. А их пихают сейчас в обычные сайты. Это вообще уже смешно. Жаль только, что с этим потом приходится кому-то разбираться.
Да, в usuario с интерфейсами и паттернами явный перебор. Архитектура для архитектуры, а не для решения задачи.
Зачем выделены мегаобщие интерфейсы типа StrategyInterface? Заменить любую стратегию на любую другую? Декорировать все и всем? Абсурд.
Пытаются создать возможность заменить что угодно на что угодно, создать абсолютную гибкость. Это ошибка. Нельзя предусмотреть все и вся наперед. Проблема известна как premature generalization. По мне нужно при проектировании определить что конкретно может измениться в будущем и оставить швы под это. Или добавлять швы, выделяя интерфейсы по мере появления необходимости в других реализациях/декорировании. Изолироваться от всего и вся создавая интерфейсы сразу и для всего - игрушки.
Согласен с BrusSENS, нужны в общем-то библиотеки, а не модули. Архитектурные решения должны приниматься исходя из бизнес-задач. Универсальные модули - миф. Разобьются о первое кастомное бизнес-требование. От них больше вреда, чем пользы в нетиповом проекте. Для типовых сайтов, да могут подойти. Но там разговоры про архитектуру не имеют смысла. На CMS стандартные магазины хорошо делаются.
О "stateless" сервисах и DiC
---------------------------------------
Будьте осторожны! В последнее время пошла мода как можно больше классов делать т.н. "stateless" и пихать все в контейнеры. Мода пришла из Java в Symfony, сейчас разносится по многим фреймворкам, в т.ч. yii. Это порочная практика. Stateless объектов не должно существовать. Иначе это не объекты, а функции. На самом деле в контейнер можно и нужно засовывать не так много. Например репозитории - они инкапсулируют соединение с БД и название таблицы/таблиц. Это их состояние. Они не stateless. Такие классы разработаны правильно и их можно пихать к контейнер. Моделируют шлюз к ханилищу. Что дают - шов для замены слоя работы с бд.
Пример-антагонист: PasswordChangerService. Инкапсулирует только UserRepository. У него есть метод execute который вытаскивает юзера и меняет ему пароль. Такие "stateless" сервисы возвращают нас к процедурному программированию. Полученный сервис это процедура, а сущность юзера это данные. Это не объекты, а функции и структуры данных, написанные в виде классов. ООП должно моделировать объекты реального мира. PasswordChangerService ничего не моделирует. Это алгоритм, а не объект.
Больно видедь конфигурацию контейнеров с сотнями инжекций, из которых реально понадобятся 2-3. а времени на разбор такого кода уйдет в 2-3 раза больше.
Про DDD и повальную моду на него
--------------------------------------------------
Люди кидаются в DDD без изучения ООП и воспринимают его с тактической стороны. Типа надо создавать сущности, сервисы, шины, события и тогда у нас будет DDD и это хорошо. Не будет. DDD это в основном про аналитическое проектирование, как разговаривать с менеджментом, как писать юзкейсы (на бумаге) а не "как назвать классы". Начинать лучше с книг по объектно-ориентированному анализу и проектированию. Вернон после этого будет читаться совсем по-другому. Хороший объектно-ориентированный код можно получить и вовсе без DDD, DiC и шин (польза шин вообще сомнительна).
Про шины
--------------
Реальных юзкейсов для шин вообще не очень много. А их пихают сейчас в обычные сайты. Это вообще уже смешно. Жаль только, что с этим потом приходится кому-то разбираться.