Понимание принципа DIP и слоев в архитектуре

Обсуждаем, как правильно строить приложения
Ответить
Аватара пользователя
pistol
Сообщения: 216
Зарегистрирован: 2014.07.12, 15:18
Откуда: Курган
Контактная информация:

Понимание принципа DIP и слоев в архитектуре

Сообщение pistol »

Добрый день! Поправьте, пожалуйста, если какие-то утверждения частично или полностью неверны:

1) Классы нижнего слоя не могут вызывать классы верхнего слоя (зависимость только сверху вниз). Слой верхнего уровня может зависеть от нижнего, но только через интерфейс.
2) Классы слоя могут вызывать только классы соседних слоев (как сверху, так и снизу) через интерфейс.
3) Любой слой можно заменить так, что соседние сверху и снизу ничего не заметят.
4) Порядок слоев сверху вниз: отображение, бизнес-логика, сервисы, данные.
Последний раз редактировалось pistol 2017.03.20, 13:40, всего редактировалось 1 раз.
Аватара пользователя
ElisDN
Сообщения: 5845
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Понимание принципа DIP и слоев в архитектуре

Сообщение ElisDN »

pistol писал(а): 2017.03.20, 13:21 Слой верхнего уровня может зависеть от нижнего, но только через интерфейс.
Через интерфейс зависимости, в основном, делаются только для инкапсуляции изменяемых частей.
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Понимание принципа DIP и слоев в архитектуре

Сообщение samdark »

1) Классы нижнего слоя не могут вызывать классы верхнего слоя — верно. Про интерфейс — не совсем. Интерфейсом выступает любой public API. Интерфейс можно выделить впоследствии, если будет нужно заменять слой.
2) Нижние верхних не вызывают. См. пункт 1.
3) В идеале да. В реальности — не всегда.
4) Это как спроектируете... слоёв может быть и меньше и больше.
Аватара пользователя
pistol
Сообщения: 216
Зарегистрирован: 2014.07.12, 15:18
Откуда: Курган
Контактная информация:

Re: Понимание принципа DIP и слоев в архитектуре

Сообщение pistol »

Спасибо. Вот еще утверждение:

5) Верхний слой может вызывать только методы соседнего нижнего слоя, но не перепрыгивать через него. Верно?

Если да, то значит на этом слайде не слоистая архитектура, бизнес-логика отделена в отдельные классы, но не слой?
http://slides.silverfire.me/2016/pdffil ... -tips/#/21

В чем тогда преимущество вынесения в отдельные классы? Просто для удобства копипаста или это какая-то отдельная архитектура, другой принцип?
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: Понимание принципа DIP и слоев в архитектуре

Сообщение anton_z »

pistol писал(а): 2017.03.21, 00:44 Спасибо. Вот еще утверждение:

5) Верхний слой может вызывать только методы соседнего нижнего слоя, но не перепрыгивать через него. Верно?

Если да, то значит на этом слайде не слоистая архитектура, бизнес-логика отделена в отдельные классы, но не слой?
http://slides.silverfire.me/2016/pdffil ... -tips/#/21

В чем тогда преимущество вынесения в отдельные классы? Просто для удобства копипаста или это какая-то отдельная архитектура, другой принцип?
Верно - не слоистая. Никакая.
Автор запрашивает объект из БД в контроллере и удаляет его из БД в сервисе. Вынес часть логики удаления записи из бд в отдельный класс. Преимущество в том, что он сможет замокать объект класса Client и тестировать ClientDeleter настоящим модульным тестом без БД.

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

Мой вывод: пример крайне простой и скорее вырожденный, нежели показательный. Пример ради примера.

Заметил ли автор, что это потуги использовать AR в качестве сущности бизнес-логики в отрыве от БД? Да, сервисный слой это хорошо. Но автору, на мой взгляд, нужно было учитывать, что если хотим изоляции от БД - нужны репозитории, AR, соответственно, в топку. Не хотим - тестируем с БД и фикстурами. Если бы он в сервис id-шку передавал, а уже внутри AR вытаскивал, а потом удалял, это было бы по крайней мере логично.

Хотелось бы обсудить данную презентацию, она ж ведь от одного из авторов фреймворка, насколько я понял. Был бы благодарен за какие-либо комментарии.

P.S. ТС рекомендую смотреть материалы по архитектуре не привязываясь к yii. Разработчики сами неоднократно высказывались, что философия yii - дать набор инструментов в виде монолитного фреймворка, а не помочь построить хорошую архитектуру. Презентации и документация - просто демонстрация возможностей фреймворка и архитектура там не при чем. Начните с книги DDD in PHP и посмотрите тему "сервисный слой, как правильно" на этом форуме. Когда почитаете книгу, надергайте отдельных библиотек через composer и постройте простое консольное слабосвязанное приложение (учебное)). Начнете по-другому смотреть на разработку.
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Понимание принципа DIP и слоев в архитектуре

Сообщение samdark »

5) Верхний слой может вызывать только методы соседнего нижнего слоя, но не перепрыгивать через него. Верно?
Да.
Хотелось бы обсудить данную презентацию, она ж ведь от одного из авторов фреймворка, насколько я понял. Был бы благодарен за какие-либо комментарии.
Позову сюда Дмитрия.
Аватара пользователя
SilverFire
Сообщения: 23
Зарегистрирован: 2013.10.24, 13:59
Откуда: Kiev
Контактная информация:

Re: Понимание принципа DIP и слоев в архитектуре

Сообщение SilverFire »

Спасибо за вопросы.
Автор пытается достичь отделения бизнес-логики от БД путем вытаскивания объекта из БД в контроллере. а выполнения операций над ним в сервисе. а не путем создания репозиториев.
Этот пример появился после того, как мне задали вопрос "А как же использовать AR, если хранить бизнес-логику одинаково плохо что в контроллерах, что в моделях?".

Так что вы совершенно правильно поняли мысль: пример описывает вариант вынесения бизнес-логики из контроллера и модели в отдельный класс, но при этом не отказываясь от использования AR.
Мой вывод: пример крайне простой и скорее вырожденный, нежели показательный. Пример ради примера.
нужно было учитывать, что если хотим изоляции от БД - нужны репозитории, AR, соответственно, в топку. Не хотим - тестируем с БД и фикстурами.
Я соглашусь, что этот пример далёк от каноничности, но ограничение по времени доклада не позволяло даже краем зацепить тему DDD, покритиковать AR и объяснить концепцию репозиториев.
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Понимание принципа DIP и слоев в архитектуре

Сообщение zelenin »

из слайдов:
Модель в MVC

Не один класс! Это целый доменный слой!
Содержит бизнес-логику
Содержит модели (таблиц, форм, ...)
следует уточнить: модель в MVC - в том числе доменный слой, т.к. модели форм или модели гридов - это не домен и не бизнес.

вообще обсуждать то в слайдах нечего - они не про слои и не про dip, а набор подсказок/рецептов.
Аватара пользователя
pistol
Сообщения: 216
Зарегистрирован: 2014.07.12, 15:18
Откуда: Курган
Контактная информация:

Re: Понимание принципа DIP и слоев в архитектуре

Сообщение pistol »

Вот еще утверждение для закрепления:

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

И еще просто туманный вопрос.

6) Существуют ли объективные критерии, которые позволяют отличить бизнес-логику от логики работы с данными? Или любая бизнес-логика - это просто манипулирование упакованными в абстракцию данными через интерфейс с понятными для любого человека названиями методов, совпадающими с именами образов в реальном мире?
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Понимание принципа DIP и слоев в архитектуре

Сообщение zelenin »

pistol писал(а): 2017.03.21, 20:106) Существуют ли объективные критерии, которые позволяют отличить бизнес-логику от логики работы с данными? Или любая бизнес-логика - это просто манипулирование упакованными в абстракцию данными через интерфейс с понятными для любого человека названиями методов?
да, бизнес-логика - это работа с данными в терминах бизнеса (если термины человекочитаемые - это супер, но суть все-таки не в названиях методов, а в самой логике, которая в них выполняется)
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: Понимание принципа DIP и слоев в архитектуре

Сообщение anton_z »

Как вариант, можно получить тестируемый код в сервисе, наподобие упомянутого и без DDD и отделения от фреймворка/библиотек.. Для этого можно использовать паттерн TableGateway. Реализация - zend-db, например. Сущности - yii\base\/Model. Шлюзы к таблицам можно будет передавать в конструктор сервиса и использовать для построения запросов. Их можно будет мокать - соответственно код сервиса будет тестируемым. Если бы через QueryBuilder yii можно было бы делать запросы на Insert/Update/Delete, тогда можно было бы использовать его.
Паттерн TableGateway как-то подзабыт в современных фреймворках. На мой взгляд, он хорошо подходит для простых приложений и код получается тестируемым. Из минусов - сложности с JOIN.

В yii не планируется TableGateway или qb для insert/update/delete?
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Понимание принципа DIP и слоев в архитектуре

Сообщение samdark »

5) Когда все становится слишком сложно, настает пора придумать еще один слой выше, который работает со всей этой сложностью через абстракцию, выступает простым бутылочным горлышком к сложному.
Да. Только не бутылочным горлышком, а понятным интерфейсом.
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Понимание принципа DIP и слоев в архитектуре

Сообщение samdark »

В yii не планируется TableGateway или qb для insert/update/delete?
Мысли были, но распланировать не хватало времени. Если кампания нормально на Patreon пойдёт, попробую что-нить запилить. Хотите ускорить — предлагайте на GitHub в деталях.
Ответить