Закон Деметры и Doctrine?

Question

[Александр]

Здравствуйте.
Есть вопрос касательно связанности модулей в веб-проекте, разрабатываемом на PHP.
В качестве ORM используется Doctrine.

Если модули не должны знать друг о друге (имеют ограниченную информацию, доступную через сервисы), то как быть с ситуацией, когда в некоторых модулях должны производиться сложные выборки с фильтрами, агрегацией, затрагивающие сущности (entity) других модулей?

Doctrine умеет хорошо управлять реляционными отношениями между сущностями. И если модули будут общаться между собой только через сервисы, и не описывая отношения через Doctrine, то это серьезно скажется на производительности.

Как тогда быть?
Заранее спасибо за ответы!

Comments

[Zhainar]

а причем тут доктрина? она всего лишь отражает то, как вы спроектируете бд. На отношения между модулями она не должна влиять.

[Александр]

Zhainar, вопрос скорее про отношения сущностей между модулями для сложных выборок. Когда нам нужно строить сложные DQL запросы, используя сущности из разных модулей.

Доктрину я здесь упомянул, чтобы у читателя скалыдвалась более общая картина о проекте и проблеме.

[Zhainar]

Александр, не вижу проблем. Если вы делаете какой-то модуль, используя только модели орм, то он не затрагивает другие модули. При этом не внося никаких изменений в эти модели.

[Сергей Горностаев]

Программирование, как инженерная дисциплина, наполнено компромиссами и контекстозависимыми истинами. Закон Деметры стоило бы переименовать в хорошее правило или полезный принцип Деметры. И даже не смотря на полезность и хорошесть, в современном программировании, где так популярны текучие интерфейсы и реактивные потоки, он часто неприменим. Так что просто имейте его ввиду и старайтесь соблюдать баланс, но не принимайте как абсолютную истину, которую нужно жёстко соблюдать всегда и везде.

[Александр]

Zhainar,
Структура модуля: "модель <- репозиторий <- сервис".
Соседние модули могут общаться друг с другом только через сервисы по паттерну DDD и Деметры.

Проблема заключается в разграниченности и ограниченности обращения, например, в ситуации, когда есть необходимость сделать сложную выборку, учитывая модели из соседних моулей.
Так как модели находятся в разных модулях и на разных слоях, возникает сложность взаимодействия для построения DQL запросов.

[Zhainar]

Александр, я не вижу нарушения принципа, если вы используете модели орм только как представления базы, то все нормально. Но если вы, к примеру, в своем модуле вызываете процедуру из другого модуля, то тут уже не все ок. Закон не ограничивает чтение данных. Он скорее ограничивает процессы модулей. Так как у вас скорее всего монолитное приложение и все модели орм разбросаны по модулям, вам нет нужды создавать модели только для чтения.

[Adamos]

Zhainar, я только сегодня узнал термин "закон Деметры" и, возможно, чего-то не понимаю.
Но если вы не можете напрочь пересобачить данные внутри одного модуля так, чтобы это не сломало работу других модулей - это ни фига не слабая связность.

[Максим Федоров]

Zhainar,

я не вижу нарушения принципа, если вы используете модели орм только как представления базы, то все нормально

если только как отображение, то вы наполните геттеруами и сеттерами сущность, а значит о ней будут знать все, куда вы закинете ее :):) это прямое нарушение закона деметры

почитать можно умной литературы, а можно простенькую мою статью: https://habr.com/ru/post/469323/?_ga=2.75845142.20...

[Zhainar]

Максим Федоров, бд доступна в любом месте кода, так что тут никакого нарушения закона. Геттеры и сеттеры тут ни причем. Как вы будете делать например отчет в админке не обращаясь к полям таблицы?

[Adamos]

Zhainar, если у вас данные любой таблицы доступны в любом месте кода - это заведомый говнокод, ибо изменение любой таблицы вынудит искать ее использование по всему коду.
Если модуль не может сам выдать данные для отчета о его работе в админке - может быть, вообще не стоит называть этот кусок кода модулем?

[Zhainar]

Adamos, в идеальном мире, это работает именно так. Но в реальном проекте какие-то модули можно ограничить, какие-то нет.

[Максим Федоров]

Zhainar, вы предлагаете то, что уже написано миллионами строк — высокосвязанный код с обычными сущностями по доке Симфони, который НАРУШАЕТ закон Деметры :) Крч как и пишут сейчас все, потому что просто и легко при написании и мало кто углубляется сильно в архитектуру и управление сложностью

У автора вопросы касаются низкой связанности — то, чего написано как раз мало и что решает проблемы высокой связанности. В больших проектах это огромная проблема, тк тонны кода, дичайшая сложность, сложное тестирвоание и куча багов

[Максим Федоров]

Zhainar, а для CRUD ваш подход вполне подходит, больших и очень громоздких проектов с тонной бизнесухи и правда не так много (но я работаю, например в таком) и да — у нас все плохо с законом Деметры

Answer 1

[Adamos]

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

Comments

[Александр]

Спасибо!
Подтолкнули на выбор нужного решения - https://www.doctrine-project.org/projects/doctrine....

Answer 2

[Максим Федоров]

то как быть с ситуацией, когда в некоторых модулях должны производиться сложные выборки с фильтрами, агрегацией, затрагивающие сущности (entity) других модулей?

Для решения задач в другом модуле/домене нет необходимости иметь сущности др проекта/модуля/бандла. Пример в модуле доставки

• не нужно знать ВСЕ о товаре и логике его сбора, нужно знать размеры и название
  
• в этом модуле не нужно знать и о заказе все — только адрес, время. История его обработки и статусы (все это есть в агрегате/сущности Заказ), влияние акций и промо — это знать не нужно, но оно есть!... передавая сущность куда-то вы передаете знания и связываете разные модули
  
• не нужно знать о пользователе много, кроме телефона, имени и адреса
  

Потому вы можете из БД выбирать только необходимые данные конкретному модулю. Этакие проекции по потребностям. Это есть соблюдение закона Деметры — вы не лезете в другой модуль, вы лезете в инфраструктуру (вселенную), которая даст вам ровно те знания и состояние, которые нужны . То есть за своими данными.. Более того эти знания могут собираться различными способами и не обязательно из реляций доставаться, а могут быть агрегированные в NoSQL виде к примеру.

Крч для одного модуля вы получаете некоторые проекции/данные, которые в этом модуле вы даже не скажете — откуда они пришли, тк нет этих знаний — из персистенс-слоя и все...