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

Обсуждаем, как правильно строить приложения
Аватара пользователя
BrusSENS
Сообщения: 565
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

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

Сообщение BrusSENS » 2019.09.30, 07:25

noLogicOnlyWar писал(а):
2019.09.29, 20:10
Вам не надоело бегать по темам и нести дичь? РТФМ как говорится.
Дичь тут только Вы несёте. DDD в PHP - бестолковая затея. Некоторая часть паттернов тупо имитируется в силу специфики работы самого PHP.

Модульность в DDD достигается с огромной болью и некоторым количеством дополнительных объектов, которые только усложняют систему. Получается уходили от сложности и к ней же возвращаемся. "Энтерпрайз" проектам вообще эти модули не облокотились 300 лет, это конкретное решение для конкретного заказчика, его никуда переносить не будут. Да и в 99% случаев такие модули будут не более, чем "переносимыми", но использоваться будут только в 1 проекте.
ElisDN писал(а):
2019.09.30, 00:47
Да уж... То у вас ООП без инкапсуляции, то теперь DDD с монолитами.

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

Так что страшно представить, как вы с таким пониманием концепций пытались всё "делать правильно" и какой монолитный трэш при этом получался. Я бы тоже такой лапшекод не полюбил.
А Вы всегда делаете выводы только со своей колокольни. Я уже понял, что есть мнение Ваше и неверное.
ElisDN писал(а):
2019.09.30, 00:47
Архитектурные вещи придумали для упрощения сложного кода, а не для усложнения простого. Если что-то код усложняет, то либо оно здесь неуместно, либо делается криво.
Именно. Посему модули в DDD с миллионами доп объектов в виде адаптеров и прочего только усложнят систему. DDD - это энтерпрайз. А в энтерпрайзе как раз и уходят к простоте, ибо такие проекты, как правило, огромные. Там куча лишних объектов "для красоты" просто не нужна. Посему и говорю, что DDD - это для сложных монолитных систем, где код явно не будет использоваться в других проектах. Зачем тогда выделение части системы в самодостаточный модуль, для которого мы будем писать адаптеры и т.п. только для того, что бы его изолировать? Ах да, нам же в крупном проекте может понадобиться его срочное отключение, забыл совсем.
anton_z писал(а):
2019.09.30, 05:35
Вы что под монолитами имеете ввиду? Я монолиты понимаю в контексте микросервисы vs монолиты. DDD с разделением на слои актуально и там и там.
Именно об этом я и пытался сказать. Можно использовать некоторые подходы, описанные в DDD парадигме. Если мы уносим управление пользователями в отдельный контекст, который многие могут назвать модулем, то это ведь не означает, что нам нужно его делать именно модулем. У нас приложение разве может отказаться от пользователей? Нет конечно. И смысл тогда этот контекст вообще изолировать? Контекст есть и можем работать с ним напрямую, не делая его абсолютно самостоятельной единицей, начиная писать для блога адаптеры, посредников и т.п., тем самым только усложняя систему, не имея от этого никакого профита. Именно это я имею ввиду, когда говорю "монолит".
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

Аватара пользователя
maleks
Сообщения: 1792
Зарегистрирован: 2012.12.26, 12:56

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

Сообщение maleks » 2019.09.30, 07:31

BrusSENS писал(а):
2019.09.29, 14:14
Видно, как человеки, увидевшие DDD начинают с головой туда вливаться, применяя даже при создании блога. Совершенное непонимание того, для чего нужны паттерны и вообще сами разговоры о том, как "правильно приготовить архитектуру".
Вы не совсем внимательно читаете или малость не в теме вопроса.
Эта тема не о DDD , а о наборе идей слоистых архитектур. То что DDD выстраивается поверх слоистых архитектур еще не делает последние DDD, а просто следствие важности разделения на слои, которое как раз улучшает:
BrusSENS писал(а):
2019.09.29, 14:14
приложение что бы оно исправно работало и его можно было поддерживать
В сторону DDD тут только Дмитрий качнул, но как выше я сказал, этот подход с POPO сущностями я не буду разбирать в этой попытке. Такой пример уже есть, если кому нужен.
Скорость разработки, да, сбавляется даже на таком, но это больше как следствие что gii такой шаблон развернуть не может.

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

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

Сообщение ElisDN » 2019.09.30, 09:08

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

Монолитность/модульность можно и без микросервисов делать в пределах одного приложения. Например, yii-shop монолитен внутри одной сильносвязанной папки shop. А пример project-manager изначально написан с разделением на независимые слабосвязанные user, projects и comments, по которым их можно хоть сейчас разнести на три микросервиса.

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

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

Сообщение ElisDN » 2019.09.30, 09:54

BrusSENS писал(а):
2019.09.30, 07:25
Модульность в DDD достигается с огромной болью и некоторым количеством дополнительных объектов, которые только усложняют систему. Получается уходили от сложности и к ней же возвращаемся.
Иметь десять аккуратных классов по 30-100 строк на 2-4 метода удобнее, чем один нетестируемый мегакласс лапшекода для всего. Так что с ростом числа объектов при разбиении большого куска кода на маленькие сложность каждого уменьшается. Если вам это приносит огромную боль, то это не значит, что у всех так.
BrusSENS писал(а):
2019.09.30, 07:25
А Вы всегда делаете выводы только со своей колокольни. Я уже понял, что есть мнение Ваше и неверное.
Да, есть наша нелюбимая вами действительность, основанная на официальных определениях и концепциях, а есть ваше личное мнение, основанное лишь на вашей фантазии. Вот, например, прямо здесь:
BrusSENS писал(а):
2019.09.30, 07:25
"Энтерпрайз" проектам вообще эти модули не облокотились 300 лет, это конкретное решение для конкретного заказчика, его никуда переносить не будут. Да и в 99% случаев такие модули будут не более, чем "переносимыми", но использоваться будут только в 1 проекте.
Читаем определения модульности и модулей в любимой вами Википедии:
Модульность — это свойство системы, связанное с возможностью её декомпозиции на ряд внутренне связанных между собой модулей. Модульный принцип — принцип построения технических систем, согласно которому функционально связанные части группируются в законченные узлы — модули (блоки).
Мо́дульное программи́рование — это организация программы как совокупности небольших независимых блоков, называемых модулями, структура и поведение которых подчиняются определённым правилам.[1] Использование модульного программирования позволяет упростить тестирование программы и обнаружение ошибок.
Мо́дульфункционально законченный фрагмент программы. Во многих языках (но далеко не обязательно) оформляется в виде отдельного файла с исходным кодом или поименованной непрерывной её части. Некоторые языки предусматривают объединение модулей в пакеты.
Везде написано про вынесение функционально-связанного кода на логические блоки для удобства независимой разработки. Мы так и говорим, что крупные проекты лучше разбивать на более мелкие модули и минимизировать связанность между ними, чтобы не утонуть в тысячах связей, ломающих соседний код при каждом мелком изменении.

А вы нам втираете дичь, что модули нужны только для переноса и обижаетесь, что мы с вашими фантазиями почему-то не соглашаемся. Не нравится реальность - сходите на митинг от оппозиции и почитайте стихи ОМОН-овцам.
Последний раз редактировалось ElisDN 2019.09.30, 10:05, всего редактировалось 1 раз.

Аватара пользователя
BrusSENS
Сообщения: 565
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

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

Сообщение BrusSENS » 2019.09.30, 10:05

maleks писал(а):
2019.09.30, 07:31
Вы не совсем внимательно читаете или малость не в теме вопроса.
Эта тема не о DDD , а о наборе идей слоистых архитектур. То что DDD выстраивается поверх слоистых архитектур еще не делает последние DDD, а просто следствие важности разделения на слои, которое как раз улучшает:
Никаких идей слоистых архитектур тут рядом нет.
Давайте посмотрим на тот код, который у Вас есть.

У Вас сущность изначально завязана на AR и Вы используете Repository.
А теперь ответьте сами себе на вопрос: "Чем же у меня является мой репозиторий?".
А репозиторий является попросту ненужной обёрткой над AR, причём доказывая, что AR объект у Вас сохраняется там, где нужно. По сути он так и сохраняет сам себя, а репозиторий просто лишний объект, который ещё и усложняет жизнь.
Скажите, вы всегда используете выборку только по ID? Думаю, что нет.
Получается нужен объект Criteria для выборки.

А что у Вас с сущностями? Получается Вы создаёте сущности даже с невалидными данными, но зачем? Разве данные не должны быть валидными при создании сущности? Опять же, проблема.
Стоп.

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

public function assignPost($postid, PostRepositoryInterface $postRepository)
{
    if ($post = $postRepository->find($postid)) {
        $this->postid = $post->id;
    }
}
Это что? Сущность узнала о репозитории? Круто. Сущность знает о хранилище, хотя для обратного мы ввели репозиторий.

В итоге из всего увиденного называется это так: Хочу юзать крутые новомодные паттерны, но от AR я не готов отказаться.
maleks писал(а):
2019.09.30, 07:31
В сторону DDD тут только Дмитрий качнул, но как выше я сказал, этот подход с POPO сущностями я не буду разбирать в этой попытке. Такой пример уже есть, если кому нужен.
Скорость разработки, да, сбавляется даже на таком, но это больше как следствие что gii такой шаблон развернуть не может.
Не все используют Gii при работе с AR. И скорость разработки сбавляется явно не от того, что Gii не используется.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

Аватара пользователя
BrusSENS
Сообщения: 565
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

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

Сообщение BrusSENS » 2019.09.30, 10:25

ElisDN писал(а):
2019.09.30, 09:54
Иметь десять аккуратных классов по 30-100 строк на 2-4 метода удобнее, чем один нетестируемый мегакласс лапшекода для всего. Так что с ростом числа объектов при разбиении большого куска кода на маленькие сложность каждого уменьшается. Если вам это приносит огромную боль, то это не значит, что у всех так.
Я и не спорю о том, что лучше разбивать на отдельные классы, но без фанатизма, когда городят вообще шляпу в виде классов-обёрток для username и т.п.
ElisDN писал(а):
2019.09.30, 09:54
Везде написано про вынесение функционально-связанного кода на логические блоки для удобства независимой разработки. Мы так и говорим, что крупные проекты лучше разбивать на более мелкие модули и минимизировать связанность между ними, чтобы не утонуть в тысячах связей, ломающих соседний код при каждом мелком изменении.
На заборе тоже много чего написано. Всё красиво, пока не начинаешь это пробовать на практике. Крупным "энтерпрайз проектам" нафиг не облокотилось разбивать на независимые модули приложение, если это может принести усложнение. Достаточно выделить такой код в некий контекст, который можно издали назвать модулем и прокинуть некий внешний API. Тем не менее, такой "модуль", как "посты" нет смысла выносить в независимый модуль. Я говорю о практике, а не о теории. Архитектурные решения нужны для решения проблем, а не для того, что бы их создавать.
ElisDN писал(а):
2019.09.30, 09:54
А вы нам втираете дичь, что модули нужны только для переноса и обижаетесь, что мы с вашими фантазиями почему-то не соглашаемся. Не нравится реальность - сходите на митинг от оппозиции и почитайте стихи ОМОН-овцам.
Именно Вы нам и втираете дичь о новомодном DDD и подобных архитектурных штуках, которые могут и ложку дёгтя в проект привнести. А всё почему? Потому что чуваки, которые только начинают знакомиться с ООП в PHP читают эту дичь и воспринимают за единственно правильное решение всех проблем. Но потом они разачаровываются во фреймворке (а бывает и в PHP в целом) и уходят на другие фреймворки (или ЯП), считая, что PHиспользуемый им инструмент очень и очень плох.
Я ещё раз повторяю, что все перечисленные в данной теме парадигмы и принципы нужно применять с головой и тогда, когда оно уместно. А не так: Запилю-ка я бложег со слоистой архитектурой (которой там нет и рядом, а только какая-то дурнопахнующая эмуляция). Я не говорю, что модули нужны только для переносимости, но полная отвязка части приложения из внутренней экосистемы, когда оно не даёт никакого значимого профита - зло и за это по рукам нужно бить. Иногда лучше тесты посложнее написать, чем усложнять сам код.
И да, на митинг Вам не помешает как раз-таки сходить, там басни про идеальную архитектуру омоновцы заценили бы.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

noLogicOnlyWar
Сообщения: 83
Зарегистрирован: 2017.07.04, 20:53

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

Сообщение noLogicOnlyWar » 2019.09.30, 10:43

Дичь тут только Вы несёте
Сильный аргумент, конечно. Вы если хотите наезжать на какую то технологию/подход/etc то потрудитесь сначала его изучить, хотя бы азы. А пока создается впечатление что вы "неосилятор" и сидите тут дуетесь на ddd.
Вы зацепились за одну неточность. Не только монолиты. В целом я с посылом BrusSENS согласен, сам придерживаюсь подобного мнения.
Того что ddd не место в PHP? Ну вы же понимаете что есть стратегические и тактические шаблоны? стратегические вообще не про языки. Тактическими уже пользуется добрая половина PHP мира (правильно или нет они их пользуют - другой вопрос). Да и язык в целом старается двигаться в сторону java и дот нет, не удивительно что в плане методик движение идет в сторону ddd, портов адаптеров и прочих слоеностей.

Аватара пользователя
samdark
Администратор
Сообщения: 9201
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

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

Сообщение samdark » 2019.09.30, 11:12

Давайте снижать накал страстей :)

С терминами, кажется, путаница. Когда обсуждение переходит в спор об определениях и в ход идут словари, диалог явно зашёл совсем не туда.

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

anton_z
Сообщения: 440
Зарегистрирован: 2017.01.15, 15:01

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

Сообщение anton_z » 2019.09.30, 11:20

ElisDN писал(а):
2019.09.30, 09:08

Монолитность/модульность можно и без микросервисов делать в пределах одного приложения. Например, yii-shop монолитен внутри одной сильносвязанной папки shop. А пример project-manager изначально написан с разделением на независимые слабосвязанные user, projects и comments, по которым их можно хоть сейчас разнести на три микросервиса.
Микросервисами оно станет только тогда, когда разнесете. Сейчас это монолит с гексагональной архитектурой.

Аватара пользователя
BrusSENS
Сообщения: 565
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

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

Сообщение BrusSENS » 2019.09.30, 11:23

noLogicOnlyWar писал(а):
2019.09.30, 10:43
Сильный аргумент, конечно. Вы если хотите наезжать на какую то технологию/подход/etc то потрудитесь сначала его изучить, хотя бы азы. А пока создается впечатление что вы "неосилятор" и сидите тут дуетесь на ddd.
Это уже обычное "меряние детородными органами". Изучил DDD я на достаточном уровне, что бы понять, что данный подход избыточен в 99% приложений.
noLogicOnlyWar писал(а):
2019.09.30, 10:43
Того что ddd не место в PHP? Ну вы же понимаете что есть стратегические и тактические шаблоны? стратегические вообще не про языки. Тактическими уже пользуется добрая половина PHP мира (правильно или нет они их пользуют - другой вопрос). Да и язык в целом старается двигаться в сторону java и дот нет, не удивительно что в плане методик движение идет в сторону ddd, портов адаптеров и прочих слоеностей.
Язык развивается, спору нет. Тем не менее сама работа PHP "Обработал запрос и умер" таковой и остаётся. Это даёт свои ограничения. Опять же, повторюсь, что я не ругаю DDD ни в коем случае, я только говорю о том, что в большинстве случаев это оверхед, который просто не нужен. И, говоря по теме, то, что выложил тс не более, чем "Хочу делать крутую архитектуру, но AR тоже хочу". Слои имеют место быть, но обдуманно, а не просто "чтобы было". Yii не мешает "слоить", но "бложек" лучше, всё-таки готовить с AR. Это быстрее и проще в поддержке.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

Аватара пользователя
BrusSENS
Сообщения: 565
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

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

Сообщение BrusSENS » 2019.09.30, 11:30

samdark писал(а):
2019.09.30, 11:12
Давайте снижать накал страстей :)

С терминами, кажется, путаница. Когда обсуждение переходит в спор об определениях и в ход идут словари, диалог явно зашёл совсем не туда.

Изначально тема была про оценку применения паттернов в учебном проекте и это ок. Замечаний про то, что в реальности надо подумать прежде чем применять паттерны достаточно. Думаю, автор суть уловил и на это можно перестать акцентировать.
Согласен :) Просто я так и не увидел объяснений ТСу того, что по сути AR и Repository ну нет смысла использовать вместе, это противоположные паттерны. Вместо указаний на крупные проблемы ElisDN начал про тонкости. final классы сущностей, гидраторы и т.п. дадут больше понимания о том, как всё-таки сделать толково, а об этом ни слова :)

UPD: И да, самое забавное, что ТС говорит о том, что у нас тут разговор не о DDD, а по сути пытается сделать дизайн архитектуры проекта основываясь на домене. И никто ему не говорит о том, что он просто именует свой подход иначе, но это остаётся попыткой Domain Driven Design'а.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

Аватара пользователя
BrusSENS
Сообщения: 565
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

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

Сообщение BrusSENS » 2019.09.30, 12:04

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

interface EventableInterface
{
    public function triggerEventDeferred(string $name, Event $event = null): void;

    public function releaseDeferredEvents(): void;

    public function triggerEvent(string $name, Event $event = null): void;
}

final class Post implements EventableInterface
{
    use EventableTrait;
    
    public const STATUS_DRAFT = 1;
    public const STATUS_PUBLISHED = 2;
    public const EVENT_PUBLISHED = 'published';

    private $id;
    private $heading;
    private $content;
    private $status;
    /**
     * @var CommentCollection
     */
    private $comments;

    public function __construct(?int $id, string $heading, string $content, int $status)
    {
        $this->id = $id;
        $this->heading = $heading;
        $this->content = $content;
        $this->status = $status;
    }

    public function getId(): ?int
    {
        return $this->id;
    }

    public function getHeading(): string
    {
        return $this->heading;
    }

    public function getContent(): string
    {
        return $this->content;
    }

    public function getComments(): CommentCollection
    {
        return $this->comments;
    }

    public function publish(): void
    {
        if ($this->status !== self::STATUS_PUBLISHED) {
            $this->status = self::STATUS_PUBLISHED;
            $this->triggerEventDeferred(self::EVENT_PUBLISHED);
        }
    }
}

interface BlogRepository
{
    public function addPost(Post $post): void;
    public function getPost(Criteria $criteria): Post;
    public function getPosts(Criteria $criteria): PostCollection;
    public function updatePost(Post $post): void;
    public function removePost(Post $post): void;
}
Вот чем плохой вариант для того, что бы оттолкнуться? DM'ы, сервисы и итератор откинул из-за долгой писанины. А ну-ка, закидайте помидорами :)
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

Аватара пользователя
maleks
Сообщения: 1792
Зарегистрирован: 2012.12.26, 12:56

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

Сообщение maleks » 2019.09.30, 14:09

BrusSENS писал(а):
2019.09.30, 10:05
1) Никаких идей слоистых архитектур тут рядом нет.
Давайте посмотрим на тот код, который у Вас есть.

2) У Вас сущность изначально завязана на AR и Вы используете Repository.
А теперь ответьте сами себе на вопрос: "Чем же у меня является мой репозиторий?".
А репозиторий является попросту ненужной обёрткой над AR, причём доказывая, что AR объект у Вас сохраняется там, где нужно. По сути он так и сохраняет сам себя, а репозиторий просто лишний объект, который ещё и усложняет жизнь.
Скажите, вы всегда используете выборку только по ID? Думаю, что нет.
Получается нужен объект Criteria для выборки.
3)
А что у Вас с сущностями? Получается Вы создаёте сущности даже с невалидными данными, но зачем? Разве данные не должны быть валидными при создании сущности? Опять же, проблема.
Стоп.

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

public function assignPost($postid, PostRepositoryInterface $postRepository)
{
    if ($post = $postRepository->find($postid)) {
        $this->postid = $post->id;
    }
}
4) Это что? Сущность узнала о репозитории? Круто. Сущность знает о хранилище, хотя для обратного мы ввели репозиторий.

5) В итоге из всего увиденного называется это так: Хочу юзать крутые новомодные паттерны, но от AR я не готов отказаться.
1) Я руководствуюсь подходом что у дяди Боба. Там слои ui - use cases - domain - infrastructure
2) Репозитории будут из в одном классе инкапсулировать выборки всех сущностей.
Понадобится, будет и не только по ID. Как минимум код выборок не раскидан непойми где
Плюс в репозитории будут прорешиваться детали, те что обычно в beforeSave...
3) Вы про создание новых? Но данные то поступают из форм валидные уже. Можно конечно ище, как anton_Z говорил, проверять валидность самой AR, эти моменты как раз дискуссионные
4) Сущность знает об интерфейсе хранилища, они лежат на одном слое.
5) Да, от AR не готов отказаться. Отказ от AR == отказ от Yii

Аватара пользователя
chungachguk
Сообщения: 425
Зарегистрирован: 2012.07.17, 11:52

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

Сообщение chungachguk » 2019.09.30, 14:17

BrusSENS писал(а):
2019.09.30, 12:04

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

...
    public function __construct(?int $id, string $heading, string $content, int $status)
    {
        $this->id = $id;
        $this->heading = $heading;
        $this->content = $content;
        $this->status = $status;
    }

    public function getId(): ?int
    {
        return $this->id;
    }
...
Вот чем плохой вариант для того, что бы оттолкнуться? DM'ы, сервисы и итератор откинул из-за долгой писанины. А ну-ка, закидайте помидорами :)
Как в таком случае задаётся ID?

anton_z
Сообщения: 440
Зарегистрирован: 2017.01.15, 15:01

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

Сообщение anton_z » 2019.09.30, 14:35

maleks писал(а):
2019.09.30, 14:09
Можно конечно ище, как anton_Z говорил, проверять валидность самой AR, эти моменты как раз дискуссионные
Я так делаю, чтобы VO не писать. а обойтись скалярными типами. Таким образом получаем, что если уж и дойдут данные до базы, то они почти наверняка будут валидными. Конечно не стоит пренебрегать тщательными проверками в классе формы и на клиенте, но еще один проверочный этап не повредит. Вообще валидацию сейчас стараюсь делать четырехуровневую: клиент -> класс формы -> AR -> БД. В AR помимо стардартных правил еще использую всякие бизнес-проверки. Очень помогает, если где-то накосячил, тесты свалятся. В итоге получается довольно надежно и писанины меньше чем с VO. А то надо VO, да потом маппер на этот VO. А с Yii + Gii почти сразу готовые AR с правилами, время экономит значительно.

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

Аватара пользователя
maleks
Сообщения: 1792
Зарегистрирован: 2012.12.26, 12:56

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

Сообщение maleks » 2019.09.30, 14:45

anton_z писал(а):
2019.09.30, 14:35
Я так делаю, чтобы VO не писать. а обойтись скалярными типами. Таким образом получаем, что если уж и дойдут данные до базы, то они почти наверняка будут валидными.
А где в моем коде лучше такую проверку - $ar->validate() - делать? В репозитории походу?

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

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

Сообщение ElisDN » 2019.09.30, 15:21

anton_z писал(а):
2019.09.30, 11:20
Микросервисами оно станет только тогда, когда разнесете. Сейчас это монолит с гексагональной архитектурой.
В плане монолит/микросервисы это монолит, так как приложение одно.

В плане монолит/модули это не монолит, так как внутри ядро с БД вертикально разделено.

А HTTP Gateway сверху всегда будет общий.

anton_z
Сообщения: 440
Зарегистрирован: 2017.01.15, 15:01

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

Сообщение anton_z » 2019.09.30, 16:50

maleks писал(а):
2019.09.30, 14:45
А где в моем коде лучше такую проверку - $ar->validate() - делать? В репозитории походу?
Там, где вызывается save(). Я это делаю внутри бизнес-методов AR, например так:

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


class Invoice extends ActiveRecord
{

      //приход денежек от ПС, в рублях
      public function pay(string $amount) : void
      {
           //транзакция...
           
           if ($this->isSufficient($amount)) {
               
               $this->status = self::STATUS_PAID;
               
               if (!$this->save()) {
                    
                    if ($this->hasErrors()) {
                         $error = array_values($this->getFirstErrors())[0];
                    } else {
                         $errror = 'Неизвестная ошибка';
                    }
                    
                    throw new \DomainException($error);
                    
               }
               
               $this->trigger(self::EVENT_PAID);
               
           }
      
      }
   

}

Можно трейт сделать с saveOrFail(), чтоб каждый раз код обработки ошибки не писать.

Аватара пользователя
BrusSENS
Сообщения: 565
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

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

Сообщение BrusSENS » 2019.09.30, 17:01

maleks писал(а):
2019.09.30, 14:09
1) Я руководствуюсь подходом что у дяди Боба. Там слои ui - use cases - domain - infrastructure
Хоть дяди Боба, хоть дяди Пети :) У Вас просто попытка изощрённо заюзать AR, не более.
maleks писал(а):
2019.09.30, 14:09
2) Репозитории будут из в одном классе инкапсулировать выборки всех сущностей.
Понадобится, будет и не только по ID. Как минимум код выборок не раскидан непойми где
Плюс в репозитории будут прорешиваться детали, те что обычно в beforeSave...
В ActiveQuery тоже ничего и нигде не раскидано. А что обычно в beforeSave()? Я вот лично года 2 уже не переопределял beforeSave...
maleks писал(а):
2019.09.30, 14:09
3) Вы про создание новых? Но данные то поступают из форм валидные уже. Можно конечно еще, как anton_Z говорил, проверять валидность самой AR, эти моменты как раз дискуссионные
т.н. "статичные конструкторы" (прости Господи) прекрасно избавляют от таких правил.
maleks писал(а):
2019.09.30, 14:09
4) Сущность знает об интерфейсе хранилища, они лежат на одном слое.
Сущность не должна знать о хранилище. От слова совсем. Хотя у Вас AR - там всё течёт по всему приложению.
maleks писал(а):
2019.09.30, 14:09
5) Да, от AR не готов отказаться. Отказ от AR == отказ от Yii
Забавно видеть, как для некоторых Yii хорош только из-за AR :)
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

Аватара пользователя
BrusSENS
Сообщения: 565
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

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

Сообщение BrusSENS » 2019.09.30, 17:02

chungachguk писал(а):
2019.09.30, 14:17
Как в таком случае задаётся ID?
А гидраторы нам на что? :)
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

Ответить