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

Кто то работал с xml сайта? http://zakupki.gov.ru/epz/main/public/home.html

Кто то работал с xml сайта? http://zakupki.gov.ru/epz/main/public/home.html

кто-то работал. Если вопрос в духе "как работать с XML" - то не тот чатик. Если вопрос в духе "как работать с XML именно этого сервиса - гугли доки по сервису"

кто-то работал. Если вопрос в духе "как работать с XML" - то не тот чатик. Если вопрос в духе "как работать с XML именно этого сервиса - гугли доки по сервису"

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

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

и как называется папка?

а хотя не, там вообще у гос закупок форум есть

и как называется папка?

новая )

(1)

и как называется папка?

control99docs например для питера будет так /fcs_regions/Sankt-Peterburg/control99docs/notifications/currMonth

это по 44 фз

Ребята, как вы боретесь с количеством зависимостей у класса? Например, классу для работы надо 4-5 репозиториев для вытаскивания данных. Аггрегировать в аля класс-коллекцию этих репозиториев, типа UserRepositoryCollector?

Если ему надо так много репозиториев то он возможно делает слишком много или сущности не собраны в агрегаты и у всего свои репозитории

для первой проблемы, если затрагивается слишком много контекстов, можно все разнести по своим местам и оповещать событиями

но судя по названию UserRepositoryCollector у вас скорее всего запчасти юзера все сами по себе а не в составе агрегата User

Ребята, как вы боретесь с количеством зависимостей у класса? Например, классу для работы надо 4-5 репозиториев для вытаскивания данных. Аггрегировать в аля класс-коллекцию этих репозиториев, типа UserRepositoryCollector?

попробуй рассказать что это за репозитории такие и почему тебе столько надо?

у меня есть классы где надо 3 репозитория но это потому что я лох и там 2 репозитория можно убрать поменяв чутка связи

но что бы 5

и наверняка у тебя помимо 5-ти репозиториев еще что-то есть, да?

попробуй рассказать что это за репозитории такие и почему тебе столько надо?

Patrik При создании пользователя, мне надо добавлять или удалять ему доступ в Компании и Приложения, добавлять или удалять Роли в зависимости от Компании и Приложения, создавать новую связь Роль-Компания-Приложения, если таковой нету, и добавлять ее для пользователя. Есть Hasher класс еще для хеширования пароля :)

Кладите их все в агрегат User и делайте все сохранение только через агрегат и UserRepository

и наверняка у тебя помимо 5-ти репозиториев еще что-то есть, да?

Patrik Проект разбил на модули Пользователи, Компании, Приложения

Кладите их все в агрегат User и делайте все сохранение только через агрегат и UserRepository

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

я использую для подобного доменные события

ну либо события да, тут уже надо смотреть где границы контекстов в его домене

1 - создать пользователя 2 - в сущности генерится ивент UserRegistered 3 - по postFlush файрю ивенты 4 - отдельные листенеры делают дела, линкуют разные агрегаты, добавляют связи и может быть статистику какую считают

плюсы: - система максимально разделена, весьма логично разделена причина и следствие - четкие границы между контекстами - мало зависимостей и легко тестить минусы: - ивенты это не очень явно, по сути надо регламентировать способ узнавать как чего работает. То есть мы должны помимо того что посмотреть код регистрации пользователей, глянуть какие ивенты генерятся и как они аффектят систему

еще я бы добавил тут контроль за тем чтобы все результаты евентов были внутри одной транзакции, если это требуется

1 - создать пользователя 2 - в сущности генерится ивент UserRegistered 3 - по postFlush файрю ивенты 4 - отдельные листенеры делают дела, линкуют разные агрегаты, добавляют связи и может быть статистику какую считают

Я так понимаю, надо эмитить ивента на preFlush-e? Ну чтобы все необходимые связи были добавлены до того, как пойдет сохранение сущностей. Или это правильно как раз?

еще я бы добавил тут контроль за тем чтобы все результаты евентов были внутри одной транзакции, если это требуется

ну у тебя корень тут будет юзер

еще я бы добавил тут контроль за тем чтобы все результаты евентов были внутри одной транзакции, если это требуется

Для работы с хранилищем юзаю Доктрину, если вы об этом. На сколько знаю, сохранение данных проводится в транзакции

Я так понимаю, надо эмитить ивента на preFlush-e? Ну чтобы все необходимые связи были добавлены до того, как пойдет сохранение сущностей. Или это правильно как раз?

нет, строго по post flush

когда данные гарантировано сохранились

все что надо делать по preFlush должно происходить в рамках агрегата юзера

(у меня это User -> Credentials, UserProfie например)

более того - в идеале должна быть возможность безболезненно ложить события в очередь например)

то есть не ок в ивент пихать саму сущность

лучше айдишку только

когда данные гарантировано сохранились

Угу, тогда нужно генерировать событие при создании Юзера, типа UserEntityCreated, чтобы можно было добавлять необходимые данные в других контекстах, как Компании, Роли и Приложения, верно?

Ну так не всегда получается, чтобы все что должно быть внутри транзакции было строго в рамках одного агрегата

лучше айдишку только

Так как проблема с вытаскиванием определенного кол-ва данных остается.

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

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

Как я написал выше Сергею, событие UserEntityCreated внутри транзакции для остальных контекстов чтобы добавить другие данные к текущей транзакции, и уже UserRegistered при postFlush для остальной системы.

Это очень интересная тема. Пытаемся разделять проект (yii2) на модули. Получается, что только использование событий позволяет обмениваться инфомрацией между модулями. Правильно ли поступаем, что создаем классы-посредники, где регистрируем обработчиков событий между разными модулями?

Да, еще интересует вопрос, как не скатиться до создания отдельных репозиториев для каждой сущности. Что есть предел агрегата и есть ли какие-то методики его ввыявления?

Гитлаб за*бал лежать б*ать

Да, еще интересует вопрос, как не скатиться до создания отдельных репозиториев для каждой сущности. Что есть предел агрегата и есть ли какие-то методики его ввыявления?

Почитайте эванса, или если совсем тяжело заходит есть https://leanpub.com/ddd-in-php

Почитайте эванса, или если совсем тяжело заходит есть https://leanpub.com/ddd-in-php

thanks :)

Уж не знаю можно ли, но для жаждущих

Правда книжка показалась уж слишком поверхностной

А кто-нибудь применяет Event Source в своих проектах?

Это какая-то кастрированная версия, там большу 300 страниц в оригинале

может быть, ибо оригинал не покупал

396 PAGES. Видимо то, что выложил, это free sample

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

плохая идея, так как это разные транзакции

у тебя остальные операции по хорошему не должны влиять на первую

Правда книжка показалась уж слишком поверхностной

ну тип так и есть)

она очень про технические моменты

но никак не про выбор агрегатов

Да, еще интересует вопрос, как не скатиться до создания отдельных репозиториев для каждой сущности. Что есть предел агрегата и есть ли какие-то методики его ввыявления?

ну у тебя должен быть репозиторий на корень агрегата и агрегаты между собой не должны особо пересекаться

у тебя остальные операции по хорошему не должны влиять на первую

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

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

типа сага? ну может быть, в моем случае у меня есть постгрес который умеет вложенные транзакции

если у тебя одна база данных проблем с этим не должно быть

а вот если в разных - то тогда начинается веселье)

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

типа сага? ну может быть, в моем случае у меня есть постгрес который умеет вложенные транзакции

А что под вложенными транзакциями имеешь в виду? savepoint ы?

А что под вложенными транзакциями имеешь в виду? savepoint ы?

угу

Знает кто хороший сервис приема биток (не блокчейн) с хорошим апи?

А что под вложенными транзакциями имеешь в виду? savepoint ы?

но честно мне ни разу не приходилось подобного делать)

В оракле есть автономные транзакции.

например нужно положить что-то в очередь для бедных (в той же базе)

не нарушая текущую транзакцию

но в целом да юзекейсы специфические

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

Какая сложность вычисления детей? Просто я обычно храню ещё left, right позицию

Взял логику у etrepat/baum

я не математик, алгоритмическим языком не могу назвать сложность. Просто рекурсия

как закончу версию на js, потом скину ссылку на гитхаб

Тема деревьем заезженна уже. Есть много разных подходов и реализаций на все случае жизни.

и без рекурсий

например nested set

гуглил я нестед сет, там все в бд делается, а тут один запрос на получения всех категорий и разбор в скрипте

там как раз один запрос для получения всего дерева

ну мне удобнее обрабатывать в скрипте а не процедуры в бд использовать

а там и не нужны процедуры

http://www.getinfo.ru/article610.html

слишком сложно

в php небольшой скрипт

https://github.com/l3pp4rd/DoctrineExtensions/blob/master/doc/tree.md

заморочек много

причем есть для любого фв