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

Обсуждаем, как правильно строить приложения
sda
Сообщения: 332
Зарегистрирован: 2013.12.19, 09:29

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

Сообщение sda » 2017.10.20, 10:30

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

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

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

Сообщение anton_z » 2017.10.20, 11:10

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

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

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

Сообщение maleks » 2017.10.20, 13:25

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

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

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

Сообщение zelenin » 2017.10.20, 13:47

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

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

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

Сообщение maleks » 2017.10.20, 14:17

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

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

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

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

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

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

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

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

Сообщение zelenin » 2017.10.20, 14:52

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

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

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

Сообщение zelenin » 2017.10.20, 15:04

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 и есть.

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

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

Сообщение zelenin » 2017.10.20, 15:10

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

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

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

Сообщение anton_z » 2017.10.20, 15:13

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

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

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

Сообщение zelenin » 2017.10.20, 15:24

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

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

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

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

Сообщение anton_z » 2017.10.20, 15:43

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

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

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

Сообщение zelenin » 2017.10.20, 15:50

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')) - как то так.

Faeron
Сообщения: 9
Зарегистрирован: 2017.10.14, 19:39

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

Сообщение Faeron » 2017.10.20, 16:25

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

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

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

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

Сообщение zelenin » 2017.10.20, 16:38

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

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

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

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

Сообщение anton_z » 2017.10.21, 03:44

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

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

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

Сообщение zelenin » 2017.10.21, 04:04

anton_z писал(а):
2017.10.21, 03:44

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

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

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

Сообщение anton_z » 2017.10.21, 04:35

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

sda
Сообщения: 332
Зарегистрирован: 2013.12.19, 09:29

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

Сообщение sda » 2017.11.14, 17:39

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

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

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

Сообщение samdark » 2017.11.14, 23:18

ACID датируется 1973 годом. MySQL создан в 1995.

Ответить