Архитектура приложения. Как сделать независимые модули (сервисы)?

Question

[vitaly_74]

Сейчас переписываю сайт на yii1.1 и столкнулся со следующей проблемой: Необходимо полностью переписать модуль либо внести какие-либо изменения. Но видя дизайн и то чего хочет от меня заказчик понимаю, что модуль нужно полностью переписывать (или пересоздавать). однако удалить его просто так тоже нельзя, поскольку в других модулях используются модели из текущего модуля.
Как в будущем можно поступить так, чтобы просто удаляя модуль система не ломалась? выносить все общие модели в отдельную папку и т.д.? т.е. все общие компоненты модуля выносить в одну общую папку? как тогда структурировать? посоветуйте пожалуйста.

Comments

[Евгений Ромашкан]

Не использовать в одном модуле модели из другого.
Не разделять админку, api, публичную часть. Это не разные модули.

[vitaly_74]

ну вот есть модуль Users и мне теперь его вообще нигде не использовать?

[Евгений Ромашкан]

vitaly_74, Что такое модуль и почему у вас есть модуль Users?

[vitaly_74]

Евгений Ромашкан, Модули - это законченные программные блоки, состоящие из моделей, представлений, контроллеров и других вспомогательных компонентов.
Нужен чтобы реализовать ЛК пользователя и т.д.

[Евгений Ромашкан]

vitaly_74,

Модули - это законченные программные блоки, состоящие из моделей, представлений, контроллеров и других вспомогательных компонентов.

Если это законченные программные блоки, почему они зависят от других программных блоков которые тоже вроде как "закончены"?

[Дмитрий]

Доброе утро.
Ознакомьтесь с этой статьёй.

[Дмитрий]

И с этой тоже.

[vitaly_74]

Евгений Ромашкан, может я не правильно понимаю слово "законченные". т.е. Эти блоки должны использовать только свои зависимости? и когда я хочу использовать, скажем класс Users, то его нужно по новой создавать в новом модуле? и по новой прописывать реляции и пр. пр. пр.?

[Евгений Ромашкан]

vitaly_74,

может я не правильно понимаю слово "законченные".

Я это слово понимаю как полностью работающий и независимый кусок системы )

и когда я хочу использовать, скажем класс Users, то его нужно по новой создавать в новом модуле?

Смотрете на вещи со стороны Coupling/Cohesion, то есть как уменьшить Coupling и повысить Cohesion. Всё это о том как уменьшить каскад изменений.
Если во всех модулях содержится одна и та же логика, что-то пошло не так при разбиении на модули.
Возможно вашему модулю от юзера нужен только его Идентификатор(id), а не вся моделька с логикой?

[vitaly_74]

Евгений Ромашкан, иной раз нужна реляция от юзера. но частенько это так (это про id), и все равно, когда пишу реляции использую какую то определенную модель.

[Максим]

vitaly_74,

может я не правильно понимаю слово "законченные". т.е. Эти блоки должны использовать только свои зависимости? и когда я хочу использовать, скажем класс Users, то его нужно по новой создавать в новом модуле? и по новой прописывать реляции и пр. пр. пр.?

В идеальности да. Не всегда пользователи являются пользователями. У вас может быть так:
"Пользователь" = некто (персона)/нечто (система), пользующееся интерфейсами (UI, API) нашей системы.
"Сотрудник" - некто (персона), имеющий отношения с нашей организацией.

Тот факт, что одна и та же персона:
- может выступать или не выступать в роли сотрудника компании
- может выступать или не выступать в роли пользователя системы,
не самый лучший способ совместить "Пользователей" и "Сотрудников" в одной таблице.

"Пользователи" - подмножество объединения "Персон" и "Систем".
"Сотрудники" - подмножество "Персон".

Пересечение "Пользователей" и "Сотрудников" в общем случае меньше и чем "Пользователи", и чем "Сотрудники".

Атрибуты "Пользователей" не пересекаются с атрибутами "Сотрудников".

У "Пользователя" есть НЕОБЯЗАТЕЛЬНАЯ ссылка на "Сотрудника" или на "Персону".
У "Сотрудника" есть НЕОБЯЗАТЕЛЬНАЯ ссылка на "Пользователя".

Вот примерно так этом может быть. Поэтому у вас есть аккаунт (user) и есть отдельные системы (модули), в которых реализованы свои сущности. Аккаунт нужен только для аунтенфикации. Пример вам этот же тостер. Здесь есть отдельный аккаунт на все его сервисы. Вы логинитесь через этот сервис-аккаунт и попадаете в сервис (модуль) тостер. или сервис (модуль) ХАБР. Но если вы заметите, то на ТОСТЕР и ХАБР есть свои сущности. Свой профиль и так далее... Поэтому с точки зрения хорошей архитектуры в модуле делается именно так.

Так же реализовано у Яндекс. Яндекс работа, знатоки, мой район...

Вы можете получать данные от USER через API. Ну если уж совсем не хотите делать свои сущности в модуле - связывайте их через Interface. Однако тут надо хорошо подумать. Иначе в базе данных будет бардак. У User будет много полей, которые не нужны ему.

[vitaly_74]

Максим, благодарю вас за развернутый ответ, сейчас склоняюсь к тому, чтобы попробовать реализовать так: сделать общий класс со всем реляциями, и для каждого модуля создавать необходимые модели без реляций. если есть необходимость, то пользоваться общими связями. например есть общая модель $dataBase - содержит реляции всего проекта. например чтобы обратиться к пользователю идем так: $dataBase->user->commnet и естественно $dataBase - вынесен в общую папку.
тогда модули будут по сути не связными, а зависеть только от одного файла - модели.

[Максим]

vitaly_74, это достаточно костыльный способ. Вы потом замучаетесь выпиливать такой класс. Ото всюду. Без поломки это тоже не закончится. Приложение должно быть надежным и сам код. Не говорю уж о тестах.

Если уж не хотите пользоваться DI контейнером, то хотя бы вынесите все зависимые классы в папку common и от этих классов наследуйте модуль. Так хотя бы будет по правилу единой отвественности.

Но я бы делал лучше и проще. Создал бы интерфейс UserInterface. В нем реализовал необходимые методы. getName() ... В коде модуля используем только этот интерфейс. Работаем только с ним. Ни каких классов User из другого модуля там быть не должно. Далее создаём в модуле класс User и наследуем его от модуля user. Имлементируем в нем UserInterface и в конфигурации приложения Через DI определяем эту зависимость. Таким образом на уровне модуля мы работаем через UserInterface, который связан с модулем User.

Теперь, если мы захоти поменять сущность User, то мы можем просто поменять наследование. А если публикуем этот модуль убираем эту сущность из модуля.

Кстати, comments это тоже независимый модуль. Связь идёт через виджет по id user->comment->getLast() плохая практика.

Ну а вообще, я думаю, что вам не нужно заморачиваться над этим. Напишите так, как вам удобно и понятно. Так чтобы вы в следующий раз при рефакторинге понимали что где и как. Документируйте. А модуль вы сейчас быстро не запилите не имея этих знаний и пониманий. Наоборот. Парясь по модульности вы ещё больше сделаете каши. Потом будете ломать голову «а за чем я так сделал» или «а как это работает»))) Делайте чтоб работало и смотрите видео 58 часов. Потихоньку учитесь и применяйте. Выйдет Yii3 - будет проще) Там модуль имеет даже свои «умные» конфигурации, как в приложении. Можно подключить композером и никакой возни. Каждая часть приложения будет писаться пакетами. Как такого класса module не будет.

Answer 1

[Максим]

По этому вопросу очень долго искал ответа))
Вам уже скинули статью по независимым модулям, но этого мало. Что вам нужно:

1. Независимый слой MODEL.
В этой папке находятся Use Case (Service), Сама сущность Entity (AR), Желательно иметь репозитории для изоляции от базы данных ну и другой доменный слой логики, который не зависит ни от чего. Ни от фреймворка, ни от других модулей и пакетов. Ваша задача написать код в этой части так, чтобы его можно было скопировать в любую папку, настроить зависимости и чтобы этот код заработал хоть на чистом PHP. Если не планируете менять фреймворк, то можно зависить от фреймворка.

2. Зависимости
Все зависимости модуля реализовать либо через Interface либо через события, но события лучше. А дальше уже синхронизируйте через приложение или отдельный модуль. Можно и по api.

3. UI (пользовательский интерфейс)
Он может быть зависимым от других модулей. В него входят: контроллеры, view, формы, vue.js и так далее. В общем то, с чем взаимодействует пользователь.

Тем самым получается такая система если опираться на MVC:
VC - могут быть зависимы от других модулей
M - не может быть зависима ни от чего, кроме PHP. Желательно и отделять слой базы данных с помощью Repository. Тогда ваш пакет будет очень сильно независим даже от базы. И вам вообще будет без разницы куда вы это храните в user или employee.

Если будет такой слой, то можно спокойно переносить хоть на будущий Yii3. Однако На Yii1 и Yii2 такое сделать сложно. Надо изворачиваться и займет это больше времени. Так как сам Фреймворк вставляет нам палки и приходится делать костыли из-за его монолитности. К такому подходу не привыкли Yii1 и Yii2 разработчики. Обычно на Yii такое понимание «фигак, фигак и в продакшн».

Такую архитектуру удобно будет строить на Symfony ну и будущем Yii3.

Рекомендую к прочтению:

• Мастер-класс Интернет-магазин на Yii2
  
• Создание архитектуры программы или как проектирова...
  
• https://www.yiiframework.ru/forum/viewtopic.php?f=...
  
• https://habr.com/ru/post/329286/
  

Comments

[vitaly_74]

Благодарю вас за ответ, не много не то что требовалось, на мой взгляд - но мне это обязательно пригодится в будущем, благодарю вас еще раз!

[Максим]

vitaly_74, поверьте. То что требовалось) Модуль - независимый пакет. Он должен быть независим. А это реализуется чаще всего абстракцией и сосредоточением кода в одной папке без торчания наружу.

[vitaly_74]

Максим, с этим согласен, система не зависит от модуля, но получилось наоборот, модуль зависит от связей. например users->billing->... как получить информацию по биллингу в самом моудуле, не обращаясь в систему.

[vitaly_74]

поэтому думаю все реляции выносить в общую папку и оттуда из этой папки запрашивать данные, которые записаны в mysql.

[Максим]

vitaly_74, Ваше право как строить архитектуру)) Можете хоть в View весь код писать вместе с HTML. Вы же спросили как сделать. Я вам ответил. А как вы будете делать - ваше решение)

Но есть хороший паттерн CQRS. В нём как раз говорится о том, как работать в таких ситуациях. Модель делится на две Command (команда) и Query (чтение). Если говорить о папках, то есть Model, а есть ReadModel.

Model - это сущности и весь независимый код. Эта часть должна быть полностью независима. И она используется только для изменения поведения системы. Если говорить о CRUD, то Model - это CUD.
ReadModel - это R - чтение. Она не изменяет поведение системы.

Что это дает? В модели мы работаем как обычно, но не используем этот слой для чтения. А в ReadModel мы используем только для чтения. Репозитории для записи и для чтения разные. В ReadModel мы можем сделать запрос хоть на голом SQL без использования объектов. А если нагрузки очень большие, то можем вынести в плоскую базу данных данные для чтения (redis), вместо СУБД.

Таким образом мы не лезем сущностью user в billing. а для вывода у пользователя историю платежей формируем в ReadModel. Которая возвращает либо массив:

user => [
       'ID' => 
       'username' => 'asdasd'
      'billing' => [
                  'id' => 1,
                  .....
      ]
]

либо View Model - специальная модель для отображения.

При таком подходе у вас код будет в модели всегда независимый и его можно копировать без опаски. Кроме того действует правило SOLID. Каждая часть отвечает за своё.

Пример такой структуры есть у Дмитрия Елисеева:
На Yii2: https://github.com/ElisDN/yii2-demo-shop
На Simfony: https://github.com/ElisDN/demo-project-manager

Чтобы понять о чём я говорю почитать статью:
https://blog.byndyu.ru/2014/07/command-and-query-r...

[vitaly_74]

Максим, Большое спасибо то что искал! Вы прям какой то профи)

[Максим]

vitaly_74, да вовсе не профи. Просто нужно изучать вопросы по архитектуре. Это удобнее и понятнее. Поэтому я пользуюсь этим. Вы сначала прочитайте то, что послал. Разберитесь. Потому что сразу реализовать не получится. Будут вопросы.

Путь архитектуры примерно такой:
ОПП->DDD->CQRS.

Если проект не сложный там можно использовать минимум - ООП или вообще без него.

Если проект с более сложной логикой и побольше - DDD.

Если у вас совсем сложный проект - CQRS.

Следующий этап это разделение на две базы данных (или денормализация данных в отдельные таблицы)

Это лично моё мнение, а не основа) Выявил для себя такие подходы. Но никто не мешает всегда работать по DDD или CQRS. Вторая не всегда подходит всем и не для всех задач. Почитайте. Однако CQRS стоит изучить для понимания и масштабирования. Такая система может масштабироваться столько угодно. Можно даже выделить отдельную команду на COMMAND и QUERY. В общем плюсов от такой архитектуры не перечесть. Но есть и минусы.