Страница 4 из 6

Re: Проектирование сущностей, сервисов и репозиториев

Добавлено: 2017.10.20, 10:30
sda
anton_z вы писали про дедупликацию, что достаточно хранить id последнего обработанного сообщения. Но producer может отправить сообщение в очередь дважды. Например если произошел сбой до того, как пришло подтверждение от очереди, что сообщение принято. При восстановлении producer отправит сообщение в очередь еще раз. Соответственно в очереди могут находиться две копии сообщения и не обязательно по порядку. Хранение id будет не достаточно.

Re: Проектирование сущностей, сервисов и репозиториев

Добавлено: 2017.10.20, 11:10
anton_z
Дедубликация должна быть на стороне слушателей, либо слушатели должны быть идемпотентными.

Re: Проектирование сущностей, сервисов и репозиториев

Добавлено: 2017.10.20, 13:25
maleks
anton_z писал(а):
2017.10.20, 02:27
но вот тут решился поделиться с сообществом и получить конструктивные замечания, быть может, я что-то упустил.
За это спасибо, эти все вещи требуют отдельной проработки на практике чтобы понять как "идет" и что вылезет. Я свое пока не думал сочинять, а на стадии поиска решений, AR то не сегодня появилась, и как то сразу - а где все профессора, к.т.н.-ы да и гении чтобы уже придти к какому то кошерному рецепту?.. Что то есть, но опять же как оно ляжет на yii, надо смотреть. Тут они походу более строги и AR дальше репозиториев не высовывают, а у вас спокойно возвращаются AR объекта из репозиториев.

Re: Проектирование сущностей, сервисов и репозиториев

Добавлено: 2017.10.20, 13:47
zelenin
maleks писал(а):
2017.10.20, 13:25
Тут они походу более строги и AR дальше репозиториев не высовывают, а у вас спокойно возвращаются AR объекта из репозиториев.
AR все равно глобально доступен, поэтому либо ты кроме программных контрактов репозиториев используешь внутрикомандные договоренности либо не используешь AR. Первый вариант выйдет боком сразу как тебе надо будет написать функциональность за 2 часа до конца рабочего дня.

Re: Проектирование сущностей, сервисов и репозиториев

Добавлено: 2017.10.20, 14:17
maleks
zelenin писал(а):
2017.10.20, 13:47
Первый вариант выйдет боком сразу как тебе надо будет написать функциональность за 2 часа до конца рабочего дня.
не вижу тут большого недостатка, а уж тем более нерешаемой проблемы, особенно по сравнению с наличием улучшенной архитектуры.

Re: Проектирование сущностей, сервисов и репозиториев

Добавлено: 2017.10.20, 14:35
anton_z
zelenin писал(а):
2017.10.20, 13:47
AR все равно глобально доступен, поэтому либо ты кроме программных контрактов репозиториев используешь внутрикомандные договоренности либо не используешь AR
Сложно нвйти проект, в котором бы не использовались внутрикомандные договоренности. Без них нет коллективной работы, а без коллективной работы и нет проекта.

А почему обязательно глобально? AR бывает и такойhttps://docs.zendframework.com/zend-db/ ... le-objects.

Re: Проектирование сущностей, сервисов и репозиториев

Добавлено: 2017.10.20, 14:52
zelenin
maleks писал(а):
2017.10.20, 14:17
zelenin писал(а):
2017.10.20, 13:47
Первый вариант выйдет боком сразу как тебе надо будет написать функциональность за 2 часа до конца рабочего дня.
не вижу тут большого недостатка, а уж тем более нерешаемой проблемы, особенно по сравнению с наличием улучшенной архитектуры.
я вижу огромный. улучшенная архитектура здесь непричем, т.к. она могла бы существовать и без AR.

Re: Проектирование сущностей, сервисов и репозиториев

Добавлено: 2017.10.20, 15:04
zelenin
anton_z писал(а):
2017.10.20, 14:35
zelenin писал(а):
2017.10.20, 13:47
AR все равно глобально доступен, поэтому либо ты кроме программных контрактов репозиториев используешь внутрикомандные договоренности либо не используешь AR
Сложно нвйти проект, в котором бы не использовались внутрикомандные договоренности. Без них нет коллективной работы, а без коллективной работы и нет проекта.
это правда. но это передергивание. когда у тебя есть только интерфейсы репозиториев, то новую функциональность без AR так или иначе придется реализовывать в рамках сложившейся архитекутуры. В случае же с AR, тебе сразу подсказывают - вот я, просто возьми меня и заюзай.
anton_z писал(а):
2017.10.20, 14:35
А почему обязательно глобально? AR бывает и такойhttps://docs.zendframework.com/zend-db/ ... le-objects.
ну я зашел по ссылке. и ничего неглобального там не увидел. отличается от yii/eloquent ar передачей db-адаптера извне. А сама реализация AR будет все равно глобальной, т.к. именно в этом AR и есть.

Re: Проектирование сущностей, сервисов и репозиториев

Добавлено: 2017.10.20, 15:10
zelenin
zelenin писал(а):
2017.10.20, 14:52
могла бы существовать и без AR.
но это без сомнения труднее реализовать. Т.к. по сути есть ужаснейшая доктрина, не позволяющая писать чистый доменный слой, и много других ORM, 4/5 которых просто не подходят под концепцию чистой архитектуры.
У меня сейчас несколько проектов параллельно, в которых я работаю в разной технике - пока меня больше всего устраивает вариант репозиториев на голых запроса, но в этом проекте у меня мало кейсов с вариантами выборок. С другой стороны в другом проекте я и с доктриной люто воюю.

Re: Проектирование сущностей, сервисов и репозиториев

Добавлено: 2017.10.20, 15:13
anton_z
zelenin писал(а):
2017.10.20, 15:04
ну я зашел по ссылке. и ничего неглобального там не увидел. отличается от yii/eloquent ar передачей db-адаптера извне. А сама реализация AR будет все равно глобальной, т.к. именно в этом AR и есть.
[/quote]
Это очень важное отличие. Пожалуйста, поясните, что будет глобального.

Re: Проектирование сущностей, сервисов и репозиториев

Добавлено: 2017.10.20, 15:24
zelenin
anton_z писал(а):
2017.10.20, 15:13
Это очень важное отличие. Пожалуйста, поясните, что будет глобального.
https://www.martinfowler.com/eaaCatalog ... ecord.html

ну вот собственно в описании ничего нет про то, откуда получаем Db connection. Главное в паттерне, что модель является 2 в 1 - и доменной сущностью и шлюзом в БД. Раз у нас сам класс доступен глобально, то глобально через него доступна и работа с базой - мы в любом месте приложения можем напрямую в обход репозитория достать из базы объекты. и это будет намного проще.

Re: Проектирование сущностей, сервисов и репозиториев

Добавлено: 2017.10.20, 15:43
anton_z
Ну 2 в 1 и глобальность никак не связаны. База через этот класс не доступна, нет адаптера, в отличие от yii/laravel, а где его взять? Можно создать шлюз к таблице и получать из него шлюзы к строкам, а шлюз к таблице из контейнера, в котором будет и объект адаптера. Глобальности как раз тут можно избежать, так как нет статики.

Re: Проектирование сущностей, сервисов и репозиториев

Добавлено: 2017.10.20, 15:50
zelenin
anton_z писал(а):
2017.10.20, 15:43
Ну 2 в 1 и глобальность никак не связаны
связаны - классы доступны глобальны, значит и вся функциональность классов доступна глобально.
anton_z писал(а):
2017.10.20, 15:43
База через этот класс не доступна, нет адаптера, в отличие от yii/laravel, а где его взять?
это AR - адаптер инкапсулируются внутри, предоставив апи работы с базой в виде insert/update/delete/save/find
anton_z писал(а):
2017.10.20, 15:43
Можно создать шлюз к таблице и получать из него шлюзы к строкам, а шлюз к таблице из контейнера, в котором будет и объект адаптера. Глобальности как раз тут можно избежать, так как нет статики.
статика для глобальности не нужна. (new Article)->find($id); из любого места приложения.
в yii1 кстати Article::model() был именно оберткой над (new Article) в виде (new CActiveRecord('Article')) - как то так.

Re: Проектирование сущностей, сервисов и репозиториев

Добавлено: 2017.10.20, 16:25
Faeron
Правильно ли понимаю, что если решил использовать в проекте Doctrine, то все модели должны быть спроектированы с этим учетом ("завязаны" на нее)?

Т.е. по сути получается сущности домена = сущность доктрины?

Re: Проектирование сущностей, сервисов и репозиториев

Добавлено: 2017.10.20, 16:38
zelenin
Faeron писал(а):
2017.10.20, 16:25
Правильно ли понимаю, что если решил использовать в проекте Doctrine, то все модели должны быть спроектированы с этим учетом ("завязаны" на нее)?

Т.е. по сути получается сущности домена = сущность доктрины?
не совсем. доктрина дает максимальную отвязку сущностей от ORM, но есть нюансы, где доктрина все равно вылезет. Самый критичный нюанс - это насильно внедряемый Collection в поля со связанными сущностями - как бы не хотелось, но придется проектировать модели с учетом этого. Плюс доктриновская реализация не разрешгает финализировать сущности (final). В принципе в остальном все более менее в контексте сущностей.
Эти нюансы обуславливаются реализацией лейзи лоада, если что.

Re: Проектирование сущностей, сервисов и репозиториев

Добавлено: 2017.10.21, 03:44
anton_z
zelenin писал(а):
2017.10.20, 15:50
статика для глобальности не нужна. (new Article)->find($id); из любого места приложения.
в yii1 кстати Article::model() был именно оберткой над (new Article) в виде (new CActiveRecord('Article')) - как то так.
Не поспоришь, объект почти любого класса досупен для создания в любом месте системы, через оператор new. Дело в зависимостях, необходимых для создания объекта. Если подключение доступно статичеcки, да, AR можно создать в любом месте системы. А если коннекшен нельзя получить где угодно, то и AR где угодно создать не получится. Паттерн AR в чистом виде не предполагает глобальности.

Re: Проектирование сущностей, сервисов и репозиториев

Добавлено: 2017.10.21, 04:04
zelenin
anton_z писал(а):
2017.10.21, 03:44

Не поспоришь, объект почти любого класса досупен для создания в любом месте системы, через оператор new. Дело в зависимостях, необходимых для создания объекта. Если подключение доступно статичеcки, да, AR можно создать в любом месте системы. А если коннекшен нельзя получить где угодно, то и AR где угодно создать не получится
согласен.
Но все же начали мы обсуждение c yii/eloquent вариантов. Вряд ли кто-то будет использовать ar не этих двух реализаций.

Re: Проектирование сущностей, сервисов и репозиториев

Добавлено: 2017.10.21, 04:35
anton_z
zelenin писал(а):
2017.10.21, 04:04
Но все же начали мы обсуждение c yii/eloquent вариантов. Вряд ли кто-то будет использовать ar не этих двух реализаций.
Это просто беда, что нет популярной и мощной реализации AR без использования статики, поэтому приходится использовать что есть.Если бы такая была, попробовал бы использовать ее в реальных проектах.

Re: Проектирование сущностей, сервисов и репозиториев

Добавлено: 2017.11.14, 17:39
sda
anton_z писал(а):
2017.10.14, 03:57
По поводу списания с баланса по событиям (Eventual Consistency) - это все очень опасно. Допустим у вас пиковая нагрузка и все воркеры заняты, ну или вообще воркеры недоступны по какой-то причине (сеть, сервер и пр.). Пользователь производит оформление, а событие еще не обработано. Пользователь может увидеть, что деньги не списались и оформить еще один или несколько заказов до первого списания. Как будете разруливать? Как объяснить пользователю, почему система дала ему оформить еще один заказ? Транзакции прекрасно решают эту задачу. Без них решить ее может и можно, но лекарство окажется хуже болезни - сложно все станет. Интернет-магазины не такие уж сложные приложения, нет там такой логики, чтобы DDD применять. Они прекрасно делались и работали до изобретения всех этих DDD и ES.
Но если посмотреть на реальный мир, то там все бизнес-процессы это eventual consistency, а не ACID. Потому что там нельзя сделать роллбек. Там конечный автомат. Бизнесмен решает, что ему делать если операция была неудачной. Например клиент съел заказ в ресторане, но оплатить его не в состоянии. Роллбек сделать невозможно. Можно лишь сделать какую-то компенсирующую операцию. Побить клиента например. Шутка. Я думаю, что в информационных системах мы также должны описывать бизнес-процессы в виде конечного автомата. ACID не работает в SOA архитектуре. ACID не существовал во времена доминирования MyISAM и я не смог найти как тогда решали проблему консистентности. Но очень интересно. Не думаю, что просто надеялись на лучшее :mrgreen:

Re: Проектирование сущностей, сервисов и репозиториев

Добавлено: 2017.11.14, 23:18
samdark
ACID датируется 1973 годом. MySQL создан в 1995.