Насчет того принимают ли заказы на разработку не смогу сказать, но эти компании с этим достаточно плотно работают, поэтому есть соответствующие компетенции :) попробуйте связаться с ними через отделы продаж
Калуга Астрал, Астрал-СОФТ, Тензор, Контур, Тинькофф, Такском, 1С - эти компании на ГОСТ алгоритмах собаку съели на ЭДО и не только :) Есть еще ИнфоТеКС которая разрабатывает один из криптопровайдеров VipNet. Или можно сразу к криптопро :)
Прежде чем использовать эту штуку, её нужно сертифицировать в ФСБ т.к. это по сути является СКЗИ (реализует ГОСТ алгоритмы). Плюс там не мало требований к самой эксплуатации :) По большому счету из-за этого все и используют платные, т.к. они сертифицированные и проблем с ними не возникнет :)
Спасибо за статью! Я ведь правильно понимаю, что правила создаются общего вида и чтобы понять нужно ли выполнить действие, мы должны событие прогнать каждое событие по всем правилам в системе? Отсюда вопрос: как решаете проблему с большим потоком событий при большом объеме правил? Например если в системе заведено 20 тысяч правил и поток событий скажем 1000 в минуту, то это означает, что при однопоточной обработке, мы должны успевать обрабатывать 16 событий в секунду (прогоняем в сумме 320к правил в секунду) или 60 мс на 1 событие на прогон 20к правил. У вас написано что вы еще куда-то в сеть ходите чтобы принять решение, в условиях такой нагрузки и объема работы, кажется нереальным куда-либо по сети ходить :) если поставщик данных зависнет на пару секунд - накопится очередь. Понятно что можно поднять пару десятков подов, побольше партиций в кафке. Правила держать в памяти пода и обновлять фоново из бд раз в N минут... :) хочется более фундаментального решения проблемы :)
Возможно Вы как-то предварительно фильтруете какие правила нужно применить (чтобы зря не жечь CPU) или они не универсальные и заточены под конкретное событие? Спасибо.
Спасибо за статью, еще добавлю: от криптопро потихоньку готовится библиотека https://github.com/CryptoPro/libcore, я его пробовал, работает вполне, но пока не все возможности имеются (см. readme)
К примеру мы достали из базы данных сущность Person, у него указан какой-то адрес (VO). Мы создали новый инстанс адреса и присвоили его к Person. У Person EntryState == modified, а у адреса он становится Added, потому что он новый. И в подобных случаях необходимо вручную указывать что на самом-то деле адрес не новый, а обновленный. Либо предусмотреть возможность полного обновления VO на основе другого VO через какой-нибудь метод)
Хочу дополнить по Owned types. К сожалению они ещё далеки от идеала. Они не могут быть Null, и их всегда нужно создавать (можно со значениями свойств по умолчанию, но это уже нарушение DDD, так как VO в некорректном состоянии).
Кроме того, EntryState у Owned Type в трекере изменений должен совпадать с его владельцем. К примеру если Entity имеет state modified, то и все его Owned Type тоже должны быть modified и наоборот. Это создает некоторые неудобства и костыли.
Насчет того принимают ли заказы на разработку не смогу сказать, но эти компании с этим достаточно плотно работают, поэтому есть соответствующие компетенции :) попробуйте связаться с ними через отделы продаж
Калуга Астрал, Астрал-СОФТ, Тензор, Контур, Тинькофф, Такском, 1С - эти компании на ГОСТ алгоритмах собаку съели на ЭДО и не только :) Есть еще ИнфоТеКС которая разрабатывает один из криптопровайдеров VipNet. Или можно сразу к криптопро :)
Прежде чем использовать эту штуку, её нужно сертифицировать в ФСБ т.к. это по сути является СКЗИ (реализует ГОСТ алгоритмы).
Плюс там не мало требований к самой эксплуатации :) По большому счету из-за этого все и используют платные, т.к. они сертифицированные и проблем с ними не возникнет :)
Спасибо за статью!
Я ведь правильно понимаю, что правила создаются общего вида и чтобы понять нужно ли выполнить действие, мы должны событие прогнать каждое событие по всем правилам в системе?
Отсюда вопрос: как решаете проблему с большим потоком событий при большом объеме правил?
Например если в системе заведено 20 тысяч правил и поток событий скажем 1000 в минуту, то это означает, что при однопоточной обработке, мы должны успевать обрабатывать 16 событий в секунду (прогоняем в сумме 320к правил в секунду) или 60 мс на 1 событие на прогон 20к правил.
У вас написано что вы еще куда-то в сеть ходите чтобы принять решение, в условиях такой нагрузки и объема работы, кажется нереальным куда-либо по сети ходить :) если поставщик данных зависнет на пару секунд - накопится очередь. Понятно что можно поднять пару десятков подов, побольше партиций в кафке. Правила держать в памяти пода и обновлять фоново из бд раз в N минут... :) хочется более фундаментального решения проблемы :)
Возможно Вы как-то предварительно фильтруете какие правила нужно применить (чтобы зря не жечь CPU) или они не универсальные и заточены под конкретное событие?
Спасибо.
Раз и два. Во втором крутой кейс со стримингом через SignalR ;-)
Спасибо за статью, еще добавлю: от криптопро потихоньку готовится библиотека https://github.com/CryptoPro/libcore, я его пробовал, работает вполне, но пока не все возможности имеются (см. readme)
Кроме того, EntryState у Owned Type в трекере изменений должен совпадать с его владельцем. К примеру если Entity имеет state modified, то и все его Owned Type тоже должны быть modified и наоборот. Это создает некоторые неудобства и костыли.