Пример чистой архитектуры на оценку

Обсуждаем, как правильно строить приложения
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: Пример чистой архитектуры на оценку

Сообщение anton_z »

maleks писал(а): 2019.09.23, 10:08 Под заковырестее я понимаю такие моменты как подсовывание AR модели через релейшены новых моделей, чтобы оно потом через специфическое поведение сохранилось как "агрегат"
Я это считаю вообще неправильным и вредным. Зачем сначала строить агрегат в память и потом целиком его сохранять? Можно ведь и кусочками в транзакции:

Код: Выделить всё


class AggregateRoot extends ActiveRecord
{

    public function changeRootAndRelationsSimultaneously(array $attributes, array $related_attributes): void
    {

        $this->scenario = self::COOL_SCENARIO;

        $this->setAttribures($attributes);

        self::getDb()->transaction(function () {

            if (!$this->save()) {
                if ($this->hasErrors()) {
                    $error = array_values($this->getFirstErrors())[0];
                } else {
                    $error = 'Unknown error';
                }
                throw new DomainException($error);
            }

            $this->unlinkAll('relation_name', true);

            foreach ($related_attributes as $item) {
                $related_model = new RelatedModel([
                    'foreign_key' => $this->id
                ]);

                $related->create($item);

            }

        });


    }

}

class RelatedModel extends ActiveRecord 
{


    public
    function create(array $attrs): void
    {
        $this->scenario = self::COOL_SCENARIO;

        $this->setAttributes($attrs);

        if (!$this->save()) {
            if ($this->hasErrors()) {
                $error = array_values($this->getFirstErrors())[0];
            } else {
                $error = 'Unknown error';
            }
            throw new DomainException($error);
        }

    }

}

maleks писал(а): 2019.09.23, 10:08 3. Это все не готово к жизни в agile, когда постоянно будет все меняться и надо переписывать, это потребует многих изменений
А я думаю наоборот. Yii как раз лучше к Agile подходит, чем DDD. Когда agile меняться может все, от данных до фронтенда. Так как нет абстрактного домена, то кода меньше, меняется быстрее.
maleks писал(а): 2019.09.23, 10:17 Забить на всю критику "старых путей", критику например этого раздела?
Да, тут понаписали много смешных вещей про "архитектуру". Я сам иногда досадую, что велся на это.
Всю эту критику можно кратко описать так:

1. Вася писал на Yii и все было ok, проекты пилились.
2. Вася прочитал книгу/статью по DDD, красивые примерчики доставили. И там было написано слово enterprise. Захотел также.
3. Вася попробовал делать на Yii как пишут в DDD/SOLID-книгах.
4. Не получилось также кошерно, как в примере в книге, вывод Yii неправильный фреймворк, и все кто его используют ошибаются. Вася идет критиковать на форум.

Подходы к Yii есть, код можно сделать хороший. Да и по мне код написанный до моды на DDD вызывает реально меньше негативных эмоций и как правило рефакторится легче.
samdark писал(а): 2019.09.23, 12:58 либо органичить себя и использовать SL только в контроллере.
Я SL юзаю посредством Instance::ensure() в методах Component::init() в том числе и в AR.
У SL две проблемы - зависимость от него и недоступность сервисов в разных контекстах (web, console).
Про первую можно вообще забыть если не пишешь библиотеку.
Второе лечится быстрым заваливанием в случае отсутствия возможности получения отдельного сервиса в конструкторах или init(), обнаруживается и фиксится быстро, особенно если есть тесты.
В остальном одни плюсы. Особенно в SL доставляет, что если есть класс A порождающий B порождающий C порождающий D, а D зависит от X, то зависимость X не нужно прокидывать начиная с A, D может получить его сам. Тестится норм, синглтоны мокаются, нужные сервисы в $app подкладываются.
Последний раз редактировалось anton_z 2019.09.23, 16:08, всего редактировалось 10 раз.
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Пример чистой архитектуры на оценку

Сообщение samdark »

Я сам иногда досадую, что велся на это.
Зря. Переболеть необходимо.
Аватара пользователя
maleks
Сообщения: 1985
Зарегистрирован: 2012.12.26, 12:56

Re: Пример чистой архитектуры на оценку

Сообщение maleks »

Выкатил новую версию , добавил в блог комментарии.

Напомню, ссылка на код тут

Итак, что изменилось:

1) Убрал в формах подгрузку рулсов и лейблов из AR модели.
Все равно если надо менять, то всякие unset из старого и merge с новым будет не сильно удобным

2) Разделил на следующие слои (то что первый уровень)

Код: Выделить всё

- application
--- service            // интерфейсы которые использует уровень приложения
--- usecase            // usecase-ы (интерфейсы и их реализации)
- domain
--- entity             // сущности
--- repository         // интерфейсы для репозиториев 
--- service            // доменные сервисы
- infrastructure
--- repository         // реализации репозиториев 
--- service            // реализации сервисов с внутренних уровней, с уровня приложения в т.ч.
- ui 
--- controllers
--- forms

3) Убрал return из сервисов, кидаю доменное исключение и логирую в контроллере

4) С сущностями стараюсь работать через отсылку им сообщений, а не манипулирования его св-вами снаружи ибо инкапсуляция.
Тут встретил момент что потребовалось прокидывание зависимости в сущность(Comment), но не в конструктор, а в метод, см. CommentService::addComment

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

Что в планах
Далее попробую добавить в приложение больше бизнес логики:
- статусы у постов чтобы можно было закрыть для комментирования
- возможно теги постам добавлю чтобы они через сущность post добавлялись или
- подписку сделать на пост чтобы при новых комментариях оповещались подписчики (через очередь)
- предлагайте на чем заковыристом можно архитектуру потестить
Yii2 universal module sceleton - for basic and advanced templates
Аватара пользователя
ElisDN
Сообщения: 5845
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Пример чистой архитектуры на оценку

Сообщение ElisDN »

1) В формах merge общих правил нужен только для CRUD, когда поля при создании и редактировании одинаковы. В других случаях мержить не понадобится.

3а) Интерфейсы сервисов PostServiceInterface для чего сейчас используете?

3б) Если у поста будет десять полей, то что будете делать с сигнатурами методов?

2) Уберите суффиксы *Interface отовсюду.

4б) Комментарию в assignPost($id) репозиторий внутри не нужен. Достаточно напрямую присвоить id.

4а) От того, что переписали с присваивания полей на вызов assignData инкапсуляции не очень добавилось. Конструкторы до сих пор пустые и доменных методов нет.

Начните сейчас использовать конструкторы и методы по назначению как в примерах. Потом пойдём дальше.
Аватара пользователя
maleks
Сообщения: 1985
Зарегистрирован: 2012.12.26, 12:56

Re: Пример чистой архитектуры на оценку

Сообщение maleks »

ElisDN писал(а): 2019.09.25, 06:50 3а) Интерфейсы сервисов PostServiceInterface для чего сейчас используете?
Пока с прицелом на будущее, чтобы если такая архитектура станет кодом расширения, можно было через DI подменить логику usecase-a
ElisDN писал(а): 2019.09.25, 06:50 3б) Если у поста будет десять полей, то что будете делать с сигнатурами методов?
В слой домена помещу DTO и его во внешних слоях буду готовить и передавать во внутрь
ElisDN писал(а): 2019.09.25, 06:50 2) Уберите суффиксы *Interface отовсюду.
С суффиксами пока привычнее выглядит, если их убрать то по путям отличаться только будут, а из путей не наглядно
ElisDN писал(а): 2019.09.25, 06:50 4б) Комментарию в assignPost($id) репозиторий внутри не нужен. Достаточно напрямую присвоить id.
Внутри присвоить или из сервиса?
Если внутри то репозиторий нужен для проверки что корректный пост присваивается, исключение будет если неверный пост
ElisDN писал(а): 2019.09.25, 06:50 - 4а) От того, что переписали с присваивания полей на вызов assignData инкапсуляции не очень добавилось. Конструкторы до сих пор пустые и доменных методов нет.
- Начните сейчас использовать конструкторы и методы по назначению как в примерах. Потом пойдём дальше.
Просмотрел пока 2 видео.
На какие конкретно конструкторы в моем коде надо обратить внимание?
Конструкторы у AR что ли?

p.s. В коде пока улучшил фабрики
Yii2 universal module sceleton - for basic and advanced templates
Аватара пользователя
ElisDN
Сообщения: 5845
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Пример чистой архитектуры на оценку

Сообщение ElisDN »

maleks писал(а): 2019.09.25, 10:20 Пока с прицелом на будущее, чтобы если такая архитектура станет кодом расширения, можно было через DI подменить логику usecase-a
Интерфейсы для сервисов делают лишь для возможности оборачивать сервисы декораторами. Это редко пригождается. А код конкретного проекта не становится расширением почти никогда.
maleks писал(а): 2019.09.25, 10:20 В слой домена помещу DTO и его во внешних слоях буду готовить и передавать во внутрь
Хорошо. Только DTO будут в юзкейсах. В домене будут объекты-значения.
maleks писал(а): 2019.09.25, 10:20 С суффиксами пока привычнее выглядит, если их убрать то по путям отличаться только будут, а из путей не наглядно
Во всех папках будут только чистые классы и интерфейсы. Реализации интерфейсов будут лежать только в папке infrastructure и использоваться только в настройках контейнера. Так что путаницы не будет и так и от суффиксов пользы никакой.
maleks писал(а): 2019.09.25, 10:20 Внутри присвоить или из сервиса?
Если внутри то репозиторий нужен для проверки что корректный пост присваивается, исключение будет если неверный пост.
Исключение кинет вызов репозитория в юзкейсе.
maleks писал(а): 2019.09.25, 10:20 На какие конкретно конструкторы в моем коде надо обратить внимание? Конструкторы у AR что ли?
Да, если делаете ООП, то делайте конструкторы и методы везде. Хоть с AR, хоть нет. Иначе "чистая архитектура" будет чистой только наполовину.

Посмотрите более продвинутый пример про доменные сущности из соседней темы и пример юзкейса, чтобы понять, что я имею в виду говоря про конструкторы, агрегаты и бизнес-логику. Ну и поковыряйте старый пример магазина или свежий менеджер проектов.
Аватара пользователя
maleks
Сообщения: 1985
Зарегистрирован: 2012.12.26, 12:56

Re: Пример чистой архитектуры на оценку

Сообщение maleks »

ElisDn писал(а):Интерфейсы для сервисов делают лишь для возможности оборачивать сервисы декораторами. Это редко пригождается. А код конкретного проекта не становится расширением почти никогда.
Я думал про такие расширения как yii2-usuario , где по сути небольшой проект.
Для них было бы неплохо подменить ихний сервис своим если ихний не позволяет то что тебе надо
ElisDn писал(а):Реализации интерфейсов будут лежать только в папке infrastructure
Cейчас у меня реализации предполагаются жить и в domain\service и в application\usecase, их как то в инфраструктуру помещать не видится правильным.
ElisDn писал(а):Да, если делаете ООП, то делайте конструкторы и методы везде. Хоть с AR, хоть нет.
Конструкторы вроде использую где надо.
С конструктором AR сущности не совсем виден профит. Передать туда ничего нельзя.
Только если грузануть зависимости.
Но что такое зависимости сущности, требуемые ей каждый момент работы?

Над остальным думаю.
Yii2 universal module sceleton - for basic and advanced templates
Аватара пользователя
maleks
Сообщения: 1985
Зарегистрирован: 2012.12.26, 12:56

Re: Пример чистой архитектуры на оценку

Сообщение maleks »

ElisDN писал(а): 2019.09.25, 12:00 Посмотрите более продвинутый пример про доменные сущности из соседней темы и
Я это смотрел раньше и пересмотрел еще раз.
С этим подходом когда "какие хочешь" доменные сущности делаешь есть большая проблема.
Съедобен он в основном только при поддержке готового датамаппера как доктрина.
Вот тот ваш способ совместить AR и чистую доменную сущность получился монструозным.
Совсем не уверен что кто то его использует.
Или встречали где нибудь в открытом, например расширениях?
Вся эта борьба за возможность использования конструктора и прочие копания в кишках yii, все эти фиксы возникающих одна за другой проблем, вряд ли останутся понятыми рядовыми членами любой среднестатистической команды.
Хотелось бы найти решение попроще. Все таки целью задавалось не DDD, а просто чистая архитектура с разделением на слои.
Yii2 universal module sceleton - for basic and advanced templates
Аватара пользователя
ElisDN
Сообщения: 5845
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Пример чистой архитектуры на оценку

Сообщение ElisDN »

maleks писал(а): 2019.09.25, 14:17 Я думал про такие расширения как yii2-usuario , где по сути небольшой проект. Для них было бы неплохо подменить ихний сервис своим если ихний не позволяет то что тебе надо
Ни один готовый модуль не подойдёт целиком для кастомного проекта. Или окажется переусложнён универсальностью. Так что вероятность публикации своего готового модуля крайне мала.
maleks писал(а): 2019.09.25, 14:17 Cейчас у меня реализации предполагаются жить и в domain\service и в application\usecase, их как то в инфраструктуру помещать не видится правильным.
У вас есть чистые интерфейсы Application\Transaction и Domain\UserRepository и есть их грязные реализации Infrastructure\YiiTransaction и Infrastructure\ARUserRepisitory. И так будет со всеми адаптерами. Так что называть оригиналы как Application\TransactionInterface нет смысла.
maleks писал(а): 2019.09.25, 14:17 Конструкторы вроде использую где надо.
Теперь да.
maleks писал(а): 2019.09.25, 14:17 С конструктором AR сущности не совсем виден профит. Передать туда ничего нельзя.
Тогда оставьте именованный конструктор create, а оригинальный конструктор объявите как protected.
Аватара пользователя
ElisDN
Сообщения: 5845
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Пример чистой архитектуры на оценку

Сообщение ElisDN »

maleks писал(а): 2019.09.25, 15:33 Я это смотрел раньше и пересмотрел еще раз.
С этим подходом когда "какие хочешь" доменные сущности делаешь есть большая проблема.
Съедобен он в основном только при поддержке готового датамаппера как доктрина.
Вот тот ваш способ совместить AR и чистую доменную сущность получился монструозным.
Совсем не уверен что кто то его использует.
Или встречали где нибудь в открытом, например расширениях?
Вся эта борьба за возможность использования конструктора и прочие копания в кишках yii, все эти фиксы возникающих одна за другой проблем, вряд ли останутся понятыми рядовыми членами любой среднестатистической команды.
Хотелось бы найти решение попроще. Все таки целью задавалось не DDD, а просто чистая архитектура с разделением на слои.
В примере магазина нет таких заморочек. Там простой переходный вариант с именованными конструкторами-фабриками create и простыми плоскими публичными AR-полями. Этого в большинстве своём достаточно.

Да, в Yii\ActiveRecord нормальное ООП делается слишком замороченно и среднестатистическая команда на Yii или в этом не разберётся и всё будет делать по-старинке. Так что есть ли вообще смысл делать это на них, превращая AR в Doctrine для людей, которые не видели Doctrine?
Последний раз редактировалось ElisDN 2019.10.02, 13:54, всего редактировалось 1 раз.
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: Пример чистой архитектуры на оценку

Сообщение anton_z »

ElisDN писал(а): 2019.09.25, 16:10
Да, в ActiveRecord нормальное ООП делается слишком замороченно и среднестатистическая команда на Yii или в этом не разберётся и всё будет делать по-старинке. Так что есть ли вообще смысл делать это на них, превращая AR в Doctrine для людей, которые не видели Doctrine?
Смотря что понимать под "нормальным ООП".
ElisDN писал(а): 2019.09.25, 12:00
Да, если делаете ООП, то делайте конструкторы и методы везде. Хоть с AR, хоть нет. Иначе "чистая архитектура" будет чистой только наполовину.
А я думаю, что "чистая архитектура" это миф. В любом реальном (не учебном) рабочем проекте найдется дерьмецо, которое будет противоречить какому-нибудь супер-пупер принципу. Конечно, правила применнять надо, декомпозицию делать, но в экстремум "чистая архитектура на 100%" я бы не возводил, дороже выйдет, выгоды не получится никакой, кроме фана и ЧСВ.
maleks писал(а): 2019.09.25, 15:33
способ совместить AR и чистую доменную сущность получился монструозным.
Поддерживаю эту точку зрения. От себя добавлю, что на мой взгляд к AR надо подходить совсем по другому, как к объекту, с помощью которого генерируются запросы к строке и подчиненным строкам в БД. И уже исходя из этого действовать и применять правила ООП.
Я пришел к выводу, что помещать данные в конструктор AR это неверно, так как AR это шлюз, зачем при создании объекта-шлюза к строке ему в конструкторе данные? Все что ему нужно это подключение к БД и зависимости (если требуются для работы). Их в Yii можно получить статически через SL, поэтому отсутствие аргументов конструктора это норма в Yii AR.


Что касается единого языка и доменного словаря, то по мне для подавляющего большинства случаев годится data dictionary и концептуальная модель данных. Просто тщательнее надо моделировать данные, чем больше констрейнтов (внешние ключи, проверяющие триггеры, CHECK constraints), тем лучше, писать комментарии к полям и таблицам, использовать CASE-средства. Модель не будет от реализации отставать. Вот и получится основа для языка, который можно использовать при общении между разработчиками. А если нужна денормализация и всякие внешние индексы типа es, то это можно реализовать на триггерах и гетерогенной репликации/поллинге, как бонус быстрее будет работать. Дешево и сердито.
Аватара пользователя
maleks
Сообщения: 1985
Зарегистрирован: 2012.12.26, 12:56

Re: Пример чистой архитектуры на оценку

Сообщение maleks »

ElisDN писал(а): 2019.09.25, 16:10 Да, в ActiveRecord нормальное ООП делается слишком замороченно и среднестатистическая команда на Yii или в этом не разберётся и всё будет делать по-старинке.
Поэтому ж я и пытался(юсь) слоистую архитектуру совместить с классическим использованием AR объектов.
В вашем примере вы по сути не используете его как AR объект.
Это у вас POPO с датамаппером(через AR) на борту.

Ведь что такое AR объект в своем обычном понимании?
Это просто строка БД, которая "ожила", что то делают с ней, что то делает она.
Изображение
ElisDN писал(а): 2019.09.25, 16:10 Так что есть ли вообще смысл делать это на них, превращая AR в Doctrine для людей, которые не видели Doctrine?
Есть опасения что практический смысл не найдется чисто по бизнес причинам.
Конечно если для себя делать то да, но насколько часто и с профитом пилится для себя..
А работу на yii найти где уже такая архитектура используется выглядит маловероятным.
Самому если ее предложить, так потом коллег не найдешь, готовых работать по такому.
Да в этом чтобы даже стартануть, чтобы руку набить и побыстрее получалось, это еще надо постараться, кто знает что там за проблемы еще вылезут.
Как профит - код чистый конечно, но сопутствующие проблемы не пустячные.
Yii2 universal module sceleton - for basic and advanced templates
MysteryDragon
Сообщения: 4
Зарегистрирован: 2013.06.25, 15:52

Re: Пример чистой архитектуры на оценку

Сообщение MysteryDragon »

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

Собственно, главное, что я хотел бы выделить (даже статью когда-то думал на эту тему написать! но не хватило времени, как часто бывает...) - о том, что вся эта сложность не нужна, говорят зачастую две категории разработчиков: или те, которым влом думать, или те, кто уже достаточно опытный. Последнее зачастую упускается.

Да, отлично всё было сказано, что нужно прийти к тому, чтобы мыслить своей головой, чтобы думать об архитектуре не только шаблонами, или вообще не шаблонами.
Как заметил тут samdark, "архитектурой надо переболеть", но порой, знаете, нужно выделить: "архитектурой надо переболеть".

Дело в том, что я знаком с определённым количеством разработчиков, которые работают на Yii (и некоторой частью из них я руковожу), и которые в какой-то момент приходят в тупик.
Сценарий довольно типичный:
- Начал свой коммерческий опыт программирования с PHP, попробовал Yii, всё здорово, всё понятно
- Использует документацию фреймворка как документ "как надо делать"
- Со временем - огроменные жирнющие ActiveRecord, куча магии в beforeSave() / afterSave() и так далее
- И вот тут ряд людей, кто стремится к совершенству (ну, или просто замучался поддерживать сложнонаписанный код) приходит к мысли: "А что я делаю не так?"

И это - очень важный момент. У этих людей порой нет в свободном доступе более скилластых ребят. Они вообще могут быть интровертами, и не искать активного общения, так тоже бывает.
Обычно как говорят: ходите на конференции, читайте умные книги, и т.д. Это всё сложно, на это часто не находят времени. И это не оправдание, нет - это факт, так просто происходит.

И вот тогда, на этом этапе, такие ребята могут найти выход в паттернах проектирования, в SOLID-е, в DDD и т.д. Эти концепции просто начинают им указывать на выходы, потому что сами они не способны достаточно легко и быстро додуматься до этого решения - быстрее, чем они просто перегорят от безуспешных ударов о стенку.)
Но это всё также - сложная теоретическая база. Это сложно сходу понять, усвоить, и дальше работать "своей головой без паттернизма и т.д." Сложно, если не переносить на практику.
И, смею сказать даже, не у всякого разработчика есть время в достаточной степени всё это практиковать на хомяках. Более того, хомяки не идут в бой. Они вне бизнес-процессов. Достаточный опыт таким образом получить весьма и весьма сложно (и долго).

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

И на мой взгляд, проблема Yii2 в том числе в том, что в этом направлении у экосистемы довольно мало чего есть. Есть утверждения "да не нужна вам эта сложность!" - но оно не учит магическим образом строить архитектуру правильно.
Хотелось бы, чтобы в программировании были ребята с отличным техническим бэкграундом - но фактически это так не срабатывает, всё та же сложность освоения сухой теории.
Я часто вижу какие-то рудименты в коде, в качестве обоснования которым мне говорят "мне так Gii сгенерировал". Я это не к тому, что Gii плох. Это я к тому, что люди доверяют, идут за тем, что им предлагает инструмент, с которым они работают.

И решение этой проблемы, как раз - это, внезапно, подобные начинания.
Да, продемонстрировать, как в Yii можно "намутить" всё по чистой архитектуре - отличное начинание!
Я часто слышал угрозы "вот сделаю шаблон для Yii2, где всё по DDD", но пока не натыкался на итоговый код в open source (хотя в последнее время искал плохо, мб уже есть?). И в том числе, так просто не наткнусь, потому что документация та же будет молчать.
И труд ElisDN также очень полезен в этом разрезе (особенно статьи - по моему личному опыту, видео смотрят реже).
И если это всё будет подано очевидно, понятно, и официально, то Yii-сообщество будет минимизировать "утечку пользователей" в тот же Symfony.

Потому что я лично некогда добавил в свою жизнь Symfony, потому что зашёл в вышеописанный тупик. НЕКОМУ было сказать, как мне делать.
Я добавил его не потому, что Yii плох, но потому, что я хотел, чтобы нечто мне помогало делать правильнее (= проще в поддержке), а в экосистеме Symfony этих примеров "архитектурно-выстроенного кода" тупо больше (и этот код объективно справлялся с проблемой лучше, чем мои жирные очень-связанные AR).
Аватара пользователя
maleks
Сообщения: 1985
Зарегистрирован: 2012.12.26, 12:56

Re: Пример чистой архитектуры на оценку

Сообщение maleks »

MysteryDragon писал(а): 2019.09.26, 10:46 а скорее про "переболеть архитектурой" и неоднозначную оценку вокруг этого высказывания
Я, если честно, не понимаю смысла этого высказывания.
Оно звучит так что мол поиграетесь в архитектуру и назад к MVC, Fat model, thin controller.
При этом мы помним что
SamDark писал(а):Yii не предлагает архитектуры. Вообще. Никакой.
А насчет:
MysteryDragon писал(а): 2019.09.26, 10:46 приходит к мысли: "А что я делаю не так?"
Они не только приходят к этой мысли а и вполне ощутимо мстят фрейму, позиционируя его как НЕ инструмент для профи. Т.е. в серцевину, по ЧСВ бьют. :)
MysteryDragon писал(а): 2019.09.26, 10:46 Это я к тому, что люди доверяют, идут за тем, что им предлагает инструмент, с которым они работают.
Да, увы, не предупредили сообщество о проблемах.
Ведь если так брать и копать то прогоны на RoR, с которого yii позаимствовал идею, пробурлили уже хрен знает когда. Даже книжка есть что то типа 40 антипаттернов в которые вы можете вляпаться в RoR проекте и как все станет печально. Для yii это ж тоже все валидно. Но тут, в пхп мире, в основном народ без мощного качественного ИТ образования, больше самоучки, поэтому такие моменты и упустили из виду. Может кого в универе научили ООП, тот и априори не будет относиться к SOLID и паттернам как к костыликам и ходункам.
Yii2 universal module sceleton - for basic and advanced templates
MysteryDragon
Сообщения: 4
Зарегистрирован: 2013.06.25, 15:52

Re: Пример чистой архитектуры на оценку

Сообщение MysteryDragon »

maleks писал(а): 2019.09.26, 13:58 Я, если честно, не понимаю смысла этого высказывания.
Оно звучит так что мол поиграетесь в архитектуру и назад к MVC, Fat model, thin controller.
При этом мы помним что
Если вдруг и звучит оно так, то не этот вывод подразумевался.)
Я верю, что samdark и anton_z подразумевают под этим именно то, что и было сказано в скинутой ими статье: "паттерны - не панацея для всего", "думайте своей головой".
Я к тому же. И про "ходунки" - отсылка к тому же (а программированию в универе я учился)): паттерны МОГУТ быть вспомогательным инструментом для того, чтобы научиться ПРАВИЛЬНО МЫСЛИТЬ.
Ведь паттерны - это ничто иное, как компиляция опыта многих отличных разработчиков по решению определенных проблем в простую и понятную (иногда)) форму
Иными словами, если ты владеешь ООП как бог, все паттерны элементарно логически выводятся без предварительного их изучения)) То есть вы начинаете разработку не с того, "а какой бы тут паттерн применить", а "как бы мне решить эту проблему", и, написав этот код, у вас могут встречаться пресловутые паттерны, а вы даже можете не знать об их существовании))
Я думаю, вышеупомянутые коллеги именно к этому апеллируют.

НО, у знания паттернов есть плюс в том, что объяснения в терминах паттернов для тех, кто их знает, может выглядеть короче.) Это как некий общий метаязык))

Тут главное - соблюдать баланс.)
Чаще всего разработчики обжигаются на чем-то, и идут в другую крайность. Но в глобальном плане для человека это естественная реакция, и принудить его соблюдать баланс - это задача разряда "обратить в буддизм")) - на словах всё понятно, а смысла и глубинной концепции без своего опыта энивей не получишь.

Поэтому своих коллег я стараюсь учить не сразу "высоким" (ну, для меня высоким)) материям, а указывать им на следующий этап для конкретно ИХ развития. Шагать по ступенькам проще, чем прыгать через них.)
Аватара пользователя
BrusSENS
Сообщения: 565
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

Re: Пример чистой архитектуры на оценку

Сообщение BrusSENS »

О Боги... Прочитал, что тут всплывает - смеяться и плакать охота.
Видно, как человеки, увидевшие DDD начинают с головой туда вливаться, применяя даже при создании блога. Совершенное непонимание того, для чего нужны паттерны и вообще сами разговоры о том, как "правильно приготовить архитектуру".
ИМХО, архитектура - это то, что создаётся умом самого разработчика и тут нет серебряной пули. Программист пишет приложение для того, что бы оно исправно работало и его можно было поддерживать. А тут получается наоборот головной боли себе накидывают и паттерны, вместо решения реальных проблем их попросту подкидывают, ибо применяются лишь с целью "поправильнее архитектуру хочу".
Модули... Модули и DDD вообще вещи, которые совершенно не совместимы, ИМХО. Слишком дорого выходит такая гибкость, сложно и вообще её не должно быть, если создаёшь приложение по канонам DDD. DDD приложения - это прежде всего монолиты, очень обдуманные монолиты, где решаются реальные проблемы.
Далее. Я тоже некоторое время болел DDD и очень хотелось делать правильно, но благо во время познакомился с C++ и с человеком, у которого опыта в разработке программного обеспечения на огромный порядок больше, причём на крестах. Я рассказал ему про красивый и крутой DDD, где всё красиво. В итоге человек просто и внятно объяснил, что DDD это очень дорого и вообще, память у приложения не безлимитная и следить за огромным количеством объектов очень сложно, мусор сам себя не удалит и вообще память может "потечь". Опять же, я пробовал делать DDD на крестах, и, скажу то, что игра стоит свечь, но там и многие паттерны можно реализовать, а не эмулировать, как на PHP это делается. Но опять же, очень дорого и нужно в 1 случае на миллион.
Так вот теперь я перестал верить в бред, о крутых приложениях c DDD.
Касательно антипаттернов. Так вот. EAV юзаем? Юзаем. Но это же антипаттерн! Аааааа, срочно бить всех адептов DDD палками, которые юзают EAV!
Так вот о чём это я... А о том, что этот новомодный DDD не более, чем модненькая штуковина, которой просто не место в PHP. Какие-то моменты безусловно заслуживают внимания, но вот воспринимать всю философию за чистую монету не стОит. Тот же SOLID можно нарушать, если ты знаешь цену и понимаешь, что ты делаешь.
Искренне желаю взглянуть на DDD под другим углом и просто разрабатывать крутые приложения, не усложняя их.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
noLogicOnlyWar
Сообщения: 83
Зарегистрирован: 2017.07.04, 20:53

Re: Пример чистой архитектуры на оценку

Сообщение noLogicOnlyWar »

DDD приложения - это прежде всего монолиты, очень обдуманные монолиты, где решаются реальные проблемы
Вам не надоело бегать по темам и нести дичь? РТФМ как говорится.
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: Пример чистой архитектуры на оценку

Сообщение anton_z »

noLogicOnlyWar писал(а): 2019.09.29, 20:10
DDD приложения - это прежде всего монолиты, очень обдуманные монолиты, где решаются реальные проблемы
Вам не надоело бегать по темам и нести дичь? РТФМ как говорится.
Вы зацепились за одну неточность. Не только монолиты. В целом я с посылом BrusSENS согласен, сам придерживаюсь подобного мнения.
Аватара пользователя
ElisDN
Сообщения: 5845
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Пример чистой архитектуры на оценку

Сообщение ElisDN »

BrusSENS писал(а): 2019.09.29, 14:14 DDD приложения - это прежде всего монолиты, очень обдуманные монолиты, где решаются реальные проблемы...
Я тоже некоторое время болел DDD и очень хотелось делать правильно...
Да уж... То у вас ООП без инкапсуляции, то теперь DDD с монолитами.

DDD наоборот максимально уводит от монолитов к разбиению на контексты-модули с минимальной связанностью.

Так что страшно представить, как вы с таким пониманием концепций пытались всё "делать правильно" и какой монолитный трэш при этом получался. Я бы тоже такой лапшекод не полюбил.
BrusSENS писал(а): 2019.09.29, 14:14 Искренне желаю взглянуть на DDD под другим углом и просто разрабатывать крутые приложения, не усложняя их.
Архитектурные вещи придумали для упрощения сложного кода, а не для усложнения простого. Если что-то код усложняет, то либо оно здесь неуместно, либо делается криво.
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: Пример чистой архитектуры на оценку

Сообщение anton_z »

ElisDN писал(а): 2019.09.30, 00:47
DDD наоборот максимально уводит от монолитов к разбиению на контексты-модули с минимальной связанностью.
Вы что под монолитами имеете ввиду? Я монолиты понимаю в контексте микросервисы vs монолиты. DDD с разделением на слои актуально и там и там. Микросервисы (и их антипод, монолиты) это не про слои, это про разделение приложения для более удобной разработки разных частей разными людьми/командами, а что внутри будет, это уже вопрос другой. Упомянутые здесь примеры приложений (yii-shop, пример ТС), являются монолитными приложениями.

Микросервисы и монолиты: разделение ответственности между людьми при разработке приложения в целом.
DDD, ООП, структурное программирование: разделение ответственности между частями одного приложения: монолита или микросервиса.

P.S. Как я уже говорил, хорошего ООП можно добиться без DDD, и код может получаться совсем не таким, как описано в DDD, но при этом это может быть хороший объектно-ориентированный код. Не надо думать что есть только лапшекод и DDD.
Ответить