Модули и подмодули. На сколько сильно дробить?

Общие вопросы по использованию второй версии фреймворка. Если не знаете как что-то сделать и это про Yii 2, вам сюда.
Ответить
myks1992@mail.ru
Сообщения: 137
Зарегистрирован: 2017.11.15, 23:54

Модули и подмодули. На сколько сильно дробить?

Сообщение myks1992@mail.ru » 2019.06.23, 21:33

Всем привет! Вопрос по модульной архитектуре. Использую её в своём проекте. Это удобно и понятно. Но немного задумался о том, на сколько сильно стоит дробить эти модули. И не мог найти ответа для себя. В документаци написано, что «неограниченны во вложенности». Однако какой этому логический предел?

Вот у меня есть независимый модуль мероприятия. Он в свою очередь делится на подмодули: соревнования, мастер-классы,батлы. В каждом этом подмодуле есть Регистрация, подсчёт баллов участника, подсчёт рейтинга. И у меня возник вопрос надо ли эти подмодули разделить ещё на подмодули: Регистрация, рейтинг, участники, счетная. По какому принципу нужно делить? Естественно, что подмодули будут взаимодействовать через абстракцию. Кстати, нужно ли подмодули абстрагировать? Ведь в целом это одна система мероприятий.

И ещё один вопрос. Нужно ли реализовывать под этот модуль свою систему авторизации и своего users? Сейчас у меня аккаунтами занимается отдельный модуль users. Я думаю, что не нужно. Но на всякий случай хочу узнать) Пока сильно во все погружаюсь.

И дополнительный вопрос к этому.Сейчас у меня есть модуль мероприятий использует список городов модуля geo где хранятся все города и регионы. Работаю с ним через интерфейсы. В базе данных просто повесил связь с этой таблицей, а в модуле city_id. В таком случае получается он не плотностью независимый. Нужно ли реализовывать свой список городов?

Аватара пользователя
leonenco
Сообщения: 126
Зарегистрирован: 2017.01.30, 22:42

Re: Модули и подмодули. На сколько сильно дробить?

Сообщение leonenco » 2019.06.24, 06:12

Мне кажется ты сильно заморачиваешься по этому поводу. Не делай сложнее чем это может быть. Каждая сущьность должна или может быть разделина на модули. Как в питоне. Дальше ты имплементишь свои реализации. Проблема всего PhP во вложенности и абстракциии. Мы абстрагируетмся всегда и по любому поводу, что приводит к многослойности системы. эта проблемма подымалась и на Симфони и в Зен. Как по мне - так если у тебя есть определенные отделы программы, то их лучше выводить в модули, так чтобы каждый компонент работал независимо от другого. Допустим у меня есть блог, и модуль товары, они не взаимосвязаны. Т.е. мы можем их вывести в модули и тем самым более структурировать наш код. ну а дальше, ваша фантазия, Опять же повтор.сь что это чисто субьективное мнение и на зе бест не претендует. Как мне кажется этот вопрос обсуждася на одном из бут кампов.

masson
Сообщения: 497
Зарегистрирован: 2012.07.03, 15:59

Re: Модули и подмодули. На сколько сильно дробить?

Сообщение masson » 2019.06.24, 11:47

myks1992@mail.ru писал(а):
2019.06.23, 21:33
задумался о том, на сколько сильно стоит дробить эти модули. И не мог найти ответа для себя. В документаци написано, что «неограниченны во вложенности». Однако какой этому логический предел?
Удобство использования и сопровождения.

myks1992@mail.ru
Сообщения: 137
Зарегистрирован: 2017.11.15, 23:54

Re: Модули и подмодули. На сколько сильно дробить?

Сообщение myks1992@mail.ru » 2019.06.24, 12:44

leonenco писал(а):
2019.06.24, 06:12
Мне кажется ты сильно заморачиваешься по этому поводу. Не делай сложнее чем это может быть. Каждая сущьность должна или может быть разделина на модули. Как в питоне. Дальше ты имплементишь свои реализации. Проблема всего PhP во вложенности и абстракциии. Мы абстрагируетмся всегда и по любому поводу, что приводит к многослойности системы. эта проблемма подымалась и на Симфони и в Зен. Как по мне - так если у тебя есть определенные отделы программы, то их лучше выводить в модули, так чтобы каждый компонент работал независимо от другого. Допустим у меня есть блог, и модуль товары, они не взаимосвязаны. Т.е. мы можем их вывести в модули и тем самым более структурировать наш код. ну а дальше, ваша фантазия, Опять же повтор.сь что это чисто субьективное мнение и на зе бест не претендует. Как мне кажется этот вопрос обсуждася на одном из бут кампов.
Понял)) Значит модули лучше не дробить, а решать вопрос структурой внутри модуля. А если у каждого модуля используются города. Получается в каждый модуль нужно свои таблицы городов, регионов, стран...?

Аватара пользователя
leonenco
Сообщения: 126
Зарегистрирован: 2017.01.30, 22:42

Re: Модули и подмодули. На сколько сильно дробить?

Сообщение leonenco » 2019.06.25, 00:28

myks1992@mail.ru писал(а):
2019.06.24, 12:44
leonenco писал(а):
2019.06.24, 06:12
Мне кажется ты сильно заморачиваешься по этому поводу. Не делай сложнее чем это может быть. Каждая сущьность должна или может быть разделина на модули. Как в питоне. Дальше ты имплементишь свои реализации. Проблема всего PhP во вложенности и абстракциии. Мы абстрагируетмся всегда и по любому поводу, что приводит к многослойности системы. эта проблемма подымалась и на Симфони и в Зен. Как по мне - так если у тебя есть определенные отделы программы, то их лучше выводить в модули, так чтобы каждый компонент работал независимо от другого. Допустим у меня есть блог, и модуль товары, они не взаимосвязаны. Т.е. мы можем их вывести в модули и тем самым более структурировать наш код. ну а дальше, ваша фантазия, Опять же повтор.сь что это чисто субьективное мнение и на зе бест не претендует. Как мне кажется этот вопрос обсуждася на одном из бут кампов.
Понял)) Значит модули лучше не дробить, а решать вопрос структурой внутри модуля. А если у каждого модуля используются города. Получается в каждый модуль нужно свои таблицы городов, регионов, стран...?
Это зависимости которые мы получаем , нормализуя БД. От этого не уйти. Некоторые модели можно выносить в common\models тем самым иметь доступ к ним для разных модулей.

myks1992@mail.ru
Сообщения: 137
Зарегистрирован: 2017.11.15, 23:54

Re: Модули и подмодули. На сколько сильно дробить?

Сообщение myks1992@mail.ru » 2019.06.25, 10:56

leonenco писал(а):
2019.06.25, 00:28
myks1992@mail.ru писал(а):
2019.06.24, 12:44
leonenco писал(а):
2019.06.24, 06:12
Мне кажется ты сильно заморачиваешься по этому поводу. Не делай сложнее чем это может быть. Каждая сущьность должна или может быть разделина на модули. Как в питоне. Дальше ты имплементишь свои реализации. Проблема всего PhP во вложенности и абстракциии. Мы абстрагируетмся всегда и по любому поводу, что приводит к многослойности системы. эта проблемма подымалась и на Симфони и в Зен. Как по мне - так если у тебя есть определенные отделы программы, то их лучше выводить в модули, так чтобы каждый компонент работал независимо от другого. Допустим у меня есть блог, и модуль товары, они не взаимосвязаны. Т.е. мы можем их вывести в модули и тем самым более структурировать наш код. ну а дальше, ваша фантазия, Опять же повтор.сь что это чисто субьективное мнение и на зе бест не претендует. Как мне кажется этот вопрос обсуждася на одном из бут кампов.
Понял)) Значит модули лучше не дробить, а решать вопрос структурой внутри модуля. А если у каждого модуля используются города. Получается в каждый модуль нужно свои таблицы городов, регионов, стран...?
Это зависимости которые мы получаем , нормализуя БД. От этого не уйти. Некоторые модели можно выносить в common\models тем самым иметь доступ к ним для разных модулей.
Я использую basic с модульной системой. Все модели и контроллеры лежат рядом
- controllers
-backend
-frontend

Поэтому common у меня нет.
У меня получается независимый модуль. Например этом в базе данных я ссылаюсь на сущности другого модуля. А самой системе получаю список городов по Ajax с url модуля geo для выпадающего списка. Вывод данных осуществляется через интерфейс CityInterface, который имеет метод getName().

Мне кажется это костылём. Так как модуль связан с другим не только через абстракцию, но и в базе. С одной стороны нормализация, но с другой связанность. Имеет ли смысл сделать денормализацию. Путём помещения в этот модуль своей таблицы городов, стран?

Аватара пользователя
leonenco
Сообщения: 126
Зарегистрирован: 2017.01.30, 22:42

Re: Модули и подмодули. На сколько сильно дробить?

Сообщение leonenco » 2019.06.25, 21:01

Если используешь чаcто одну модель, создай папку models в root и юзай ее для всех модулей.

Аватара пользователя
ElisDN
Сообщения: 5419
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Модули и подмодули. На сколько сильно дробить?

Сообщение ElisDN » 2019.06.25, 22:07

Лишняя связанность мешает при программировании сущностей и юзкейсов, но безопасна для рендеринга страницы. Если разделять Model и ReadModel, то можно не добавлять лишние связи в Model.

Например, в текущем демо-проекте в Model есть независимые модули User, Work и Comment. У сущности Comment есть лишь поля autorId для id автора и entityType с entityId для id материала, что даёт возможность создавать комментарии какими угодно сущностями авторов для каких угодно материалов.

В Model хочется иметь максимально независимые доменные сущности и юзкейсы без JOIN-ов, но для вывода на HTML-страницах нужны кучи связей с JOIN-ами. Как быть?

И здесь уже, чтобы не добавлять кучу связей в Model для вывода на страницах, можно сделать отдельную ReadModel с произвольными SQL-запросами. Например, для задачи Model\Work\Task имеется отдельный класс ReadModel\Work\Task\CommentFetcher, выводящий список комментариев для задачи. И там уже под нашу вёрстку JOIN-ится список SELECT ... FROM comments с JOIN work_members m WHERE c.entity_id = :task_id.

Из Web-MVC в модулях сделаны независимыми только M (Entity, Service, UseCase). А снаружи всё так или иначе в зависимости от вёрстки будет переплетаться в VC (Controller, Fetcher, View). Например, в TaskController нужно будет вывести CommentForm, а в UserController в грид пользователей добавить колонку с числом комментариев.

Так что смешивать модели опасно, а смешивать представления необходимо. Как видим, решением является выделение DomainModel с бизнес-логикой из сущностей и сервисов и создание отдельной ReadModel для SELECT-ов.

Поэтому оптимальный вариант для изоляции - в каждом модуле оставить только доменную модель с ActiveRecord или с Doctrine без внешних связей. Там мы просто в $competition присваиваем значение city_id = $cityId.

А внешнюю оболочку сайта из контроллеров с фетчерами и представленими с виджетами вынести наружу модулей в корневые папки controllers и views. И там уже, не заморачиваясь, спокойно JOIN-ить что угодно к чему угодно из разных модулей голыми SQL-запросами вроде SELECT ... FROM competitions JOIN geo_cities JOIN members без ActiveRecord. Или с отдельными ActiveRecord, специально сделанными для этих выборок.

Ну или если не очень хочется заморачиваться, то можно оставить как есть и переплести всё связями вроде $competition->city->name и $competition->author->user->name, осознанно сделав модули немного зависимыми от общих geo и user.

myks1992@mail.ru
Сообщения: 137
Зарегистрирован: 2017.11.15, 23:54

Re: Модули и подмодули. На сколько сильно дробить?

Сообщение myks1992@mail.ru » 2019.06.25, 22:34

ElisDN писал(а):
2019.06.25, 22:07
Лишняя связанность мешает при программировании сущностей и юзкейсов, но безопасна для рендеринга страницы. Если разделять Model и ReadModel, то можно не добавлять лишние связи в Model.

Например, в текущем демо-проекте в Model есть независимые модули User, Work и Comment. У сущности Comment есть лишь поля autorId для id автора и entityType с entityId для id материала, что даёт возможность создавать комментарии какими угодно сущностями авторов для каких угодно материалов.

В Model хочется иметь максимально независимые доменные сущности и юзкейсы без JOIN-ов, но для вывода на HTML-страницах нужны кучи связей с JOIN-ами. Как быть?

И здесь уже, чтобы не добавлять кучу связей в Model для вывода на страницах, можно сделать отдельную ReadModel с произвольными SQL-запросами. Например, для задачи Model\Work\Task имеется отдельный класс ReadModel\Work\Task\CommentFetcher, выводящий список комментариев для задачи. И там уже под нашу вёрстку JOIN-ится список SELECT ... FROM comments с JOIN work_members m WHERE c.entity_id = :task_id.

Из Web-MVC в модулях сделаны независимыми только M (Entity, Service, UseCase). А снаружи всё так или иначе в зависимости от вёрстки будет переплетаться в VC (Controller, Fetcher, View). Например, в TaskController нужно будет вывести CommentForm, а в UserController в грид пользователей добавить колонку с числом комментариев.

Так что смешивать модели опасно, а смешивать представления необходимо. Как видим, решением является выделение DomainModel с бизнес-логикой из сущностей и сервисов и создание отдельной ReadModel для SELECT-ов.

Поэтому оптимальный вариант для изоляции - в каждом модуле оставить только доменную модель с ActiveRecord или с Doctrine без внешних связей. Там мы просто в $competition присваиваем значение city_id = $cityId.

А внешнюю оболочку сайта из контроллеров с фетчерами и представленими с виджетами вынести наружу модулей в корневые папки controllers и views. И там уже, не заморачиваясь, спокойно JOIN-ить что угодно к чему угодно из разных модулей голыми SQL-запросами вроде SELECT ... FROM competitions JOIN geo_cities JOIN members без ActiveRecord. Или с отдельными ActiveRecord, специально сделанными для этих выборок.

Ну или если не очень хочется заморачиваться, то можно оставить как есть и переплести всё связями вроде $competition->city->name и $competition->author->user->name, осознанно сделав модули немного зависимыми от общих geo и user.
Теперь всё понятно!))) А я не мог соотнести независимость модулей, таблицы, представления и контроллеры) Я думал так, если модуль независимый, то и VC, а так же сама база данных должна быть независима. Соотвественно если мне нужны города в независимом модуле, то нужно их туда поместить)) Хорошо что не начал этого делать, но и хорошо что не стал делать свои сущности города.Как же хорошо, когда все по полочкам))
Последний раз редактировалось myks1992@mail.ru 2019.06.26, 00:50, всего редактировалось 1 раз.

Аватара пользователя
ElisDN
Сообщения: 5419
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Модули и подмодули. На сколько сильно дробить?

Сообщение ElisDN » 2019.06.25, 23:53

P.S. Перенесите тему в раздел "Архитектура".

Ответить