Проектирование сущностей, сервисов и репозиториев
Re: Проектирование сущностей, сервисов и репозиториев
anton_z вы писали про дедупликацию, что достаточно хранить id последнего обработанного сообщения. Но producer может отправить сообщение в очередь дважды. Например если произошел сбой до того, как пришло подтверждение от очереди, что сообщение принято. При восстановлении producer отправит сообщение в очередь еще раз. Соответственно в очереди могут находиться две копии сообщения и не обязательно по порядку. Хранение id будет не достаточно.
Re: Проектирование сущностей, сервисов и репозиториев
Дедубликация должна быть на стороне слушателей, либо слушатели должны быть идемпотентными.
Re: Проектирование сущностей, сервисов и репозиториев
За это спасибо, эти все вещи требуют отдельной проработки на практике чтобы понять как "идет" и что вылезет. Я свое пока не думал сочинять, а на стадии поиска решений, AR то не сегодня появилась, и как то сразу - а где все профессора, к.т.н.-ы да и гении чтобы уже придти к какому то кошерному рецепту?.. Что то есть, но опять же как оно ляжет на yii, надо смотреть. Тут они походу более строги и AR дальше репозиториев не высовывают, а у вас спокойно возвращаются AR объекта из репозиториев.
Re: Проектирование сущностей, сервисов и репозиториев
AR все равно глобально доступен, поэтому либо ты кроме программных контрактов репозиториев используешь внутрикомандные договоренности либо не используешь AR. Первый вариант выйдет боком сразу как тебе надо будет написать функциональность за 2 часа до конца рабочего дня.
Re: Проектирование сущностей, сервисов и репозиториев
Сложно нвйти проект, в котором бы не использовались внутрикомандные договоренности. Без них нет коллективной работы, а без коллективной работы и нет проекта.
А почему обязательно глобально? AR бывает и такойhttps://docs.zendframework.com/zend-db/ ... le-objects.
Re: Проектирование сущностей, сервисов и репозиториев
Re: Проектирование сущностей, сервисов и репозиториев
это правда. но это передергивание. когда у тебя есть только интерфейсы репозиториев, то новую функциональность без AR так или иначе придется реализовывать в рамках сложившейся архитекутуры. В случае же с AR, тебе сразу подсказывают - вот я, просто возьми меня и заюзай.
ну я зашел по ссылке. и ничего неглобального там не увидел. отличается от yii/eloquent ar передачей db-адаптера извне. А сама реализация AR будет все равно глобальной, т.к. именно в этом AR и есть.anton_z писал(а): ↑2017.10.20, 14:35А почему обязательно глобально? AR бывает и такойhttps://docs.zendframework.com/zend-db/ ... le-objects.
Re: Проектирование сущностей, сервисов и репозиториев
но это без сомнения труднее реализовать. Т.к. по сути есть ужаснейшая доктрина, не позволяющая писать чистый доменный слой, и много других ORM, 4/5 которых просто не подходят под концепцию чистой архитектуры.
У меня сейчас несколько проектов параллельно, в которых я работаю в разной технике - пока меня больше всего устраивает вариант репозиториев на голых запроса, но в этом проекте у меня мало кейсов с вариантами выборок. С другой стороны в другом проекте я и с доктриной люто воюю.
Re: Проектирование сущностей, сервисов и репозиториев
ну я зашел по ссылке. и ничего неглобального там не увидел. отличается от yii/eloquent ar передачей db-адаптера извне. А сама реализация AR будет все равно глобальной, т.к. именно в этом AR и есть.
[/quote]
Это очень важное отличие. Пожалуйста, поясните, что будет глобального.
Re: Проектирование сущностей, сервисов и репозиториев
https://www.martinfowler.com/eaaCatalog ... ecord.html
ну вот собственно в описании ничего нет про то, откуда получаем Db connection. Главное в паттерне, что модель является 2 в 1 - и доменной сущностью и шлюзом в БД. Раз у нас сам класс доступен глобально, то глобально через него доступна и работа с базой - мы в любом месте приложения можем напрямую в обход репозитория достать из базы объекты. и это будет намного проще.
Re: Проектирование сущностей, сервисов и репозиториев
Ну 2 в 1 и глобальность никак не связаны. База через этот класс не доступна, нет адаптера, в отличие от yii/laravel, а где его взять? Можно создать шлюз к таблице и получать из него шлюзы к строкам, а шлюз к таблице из контейнера, в котором будет и объект адаптера. Глобальности как раз тут можно избежать, так как нет статики.
Re: Проектирование сущностей, сервисов и репозиториев
связаны - классы доступны глобальны, значит и вся функциональность классов доступна глобально.
это AR - адаптер инкапсулируются внутри, предоставив апи работы с базой в виде insert/update/delete/save/find
статика для глобальности не нужна. (new Article)->find($id); из любого места приложения.
в yii1 кстати Article::model() был именно оберткой над (new Article) в виде (new CActiveRecord('Article')) - как то так.
Re: Проектирование сущностей, сервисов и репозиториев
Правильно ли понимаю, что если решил использовать в проекте Doctrine, то все модели должны быть спроектированы с этим учетом ("завязаны" на нее)?
Т.е. по сути получается сущности домена = сущность доктрины?
Т.е. по сути получается сущности домена = сущность доктрины?
Re: Проектирование сущностей, сервисов и репозиториев
не совсем. доктрина дает максимальную отвязку сущностей от ORM, но есть нюансы, где доктрина все равно вылезет. Самый критичный нюанс - это насильно внедряемый Collection в поля со связанными сущностями - как бы не хотелось, но придется проектировать модели с учетом этого. Плюс доктриновская реализация не разрешгает финализировать сущности (final). В принципе в остальном все более менее в контексте сущностей.
Эти нюансы обуславливаются реализацией лейзи лоада, если что.
Re: Проектирование сущностей, сервисов и репозиториев
Не поспоришь, объект почти любого класса досупен для создания в любом месте системы, через оператор new. Дело в зависимостях, необходимых для создания объекта. Если подключение доступно статичеcки, да, AR можно создать в любом месте системы. А если коннекшен нельзя получить где угодно, то и AR где угодно создать не получится. Паттерн AR в чистом виде не предполагает глобальности.
Re: Проектирование сущностей, сервисов и репозиториев
согласен.anton_z писал(а): ↑2017.10.21, 03:44
Не поспоришь, объект почти любого класса досупен для создания в любом месте системы, через оператор new. Дело в зависимостях, необходимых для создания объекта. Если подключение доступно статичеcки, да, AR можно создать в любом месте системы. А если коннекшен нельзя получить где угодно, то и AR где угодно создать не получится
Но все же начали мы обсуждение c yii/eloquent вариантов. Вряд ли кто-то будет использовать ar не этих двух реализаций.
Re: Проектирование сущностей, сервисов и репозиториев
Это просто беда, что нет популярной и мощной реализации AR без использования статики, поэтому приходится использовать что есть.Если бы такая была, попробовал бы использовать ее в реальных проектах.
Re: Проектирование сущностей, сервисов и репозиториев
Но если посмотреть на реальный мир, то там все бизнес-процессы это eventual consistency, а не ACID. Потому что там нельзя сделать роллбек. Там конечный автомат. Бизнесмен решает, что ему делать если операция была неудачной. Например клиент съел заказ в ресторане, но оплатить его не в состоянии. Роллбек сделать невозможно. Можно лишь сделать какую-то компенсирующую операцию. Побить клиента например. Шутка. Я думаю, что в информационных системах мы также должны описывать бизнес-процессы в виде конечного автомата. ACID не работает в SOA архитектуре. ACID не существовал во времена доминирования MyISAM и я не смог найти как тогда решали проблему консистентности. Но очень интересно. Не думаю, что просто надеялись на лучшееanton_z писал(а): ↑2017.10.14, 03:57 По поводу списания с баланса по событиям (Eventual Consistency) - это все очень опасно. Допустим у вас пиковая нагрузка и все воркеры заняты, ну или вообще воркеры недоступны по какой-то причине (сеть, сервер и пр.). Пользователь производит оформление, а событие еще не обработано. Пользователь может увидеть, что деньги не списались и оформить еще один или несколько заказов до первого списания. Как будете разруливать? Как объяснить пользователю, почему система дала ему оформить еще один заказ? Транзакции прекрасно решают эту задачу. Без них решить ее может и можно, но лекарство окажется хуже болезни - сложно все станет. Интернет-магазины не такие уж сложные приложения, нет там такой логики, чтобы DDD применять. Они прекрасно делались и работали до изобретения всех этих DDD и ES.
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Проектирование сущностей, сервисов и репозиториев
ACID датируется 1973 годом. MySQL создан в 1995.
Нравится Yii? Давайте сделаем его лучше!.