для чего нужна целостность данных
Для чего используется свойство обеспечения целостности данных?
Содержание:
Прежде чем узнать зачем используется свойство целостности данных, давайте выясним, что понимается под этим определением.
Целостность данных — это термин, который часто используется в информатике. Он означает, что имеющиеся данные полны и условия по обеспечению их безопасности полностью соблюдены. А это значит, что с информацией никаких изменений ни под каким предлогом не производилось. Другими словами, целостность данных — это специальное их свойство, которое своим выполнением обеспечивает данным определенный вид и надлежащее качество.
Зачем используется свойство обеспечения целостности данных
Свойства обеспечения целостности данных, допустим в Microsoft Access — это свод определенных правил, которые используются для поддержки постоянных связей между записями в связанных таблицах базы данных. Также этот свод правил гарантирует отсутствие случайного удаления данных или неправомерное изменение их связей.
Если применять свойство обеспечения целостности данных на практике, то это будет означать:
Заключение
Зачем используется свойство целостности данных в Microsoft Access? Это помогает сохранить данные с корректными связями между разными таблицами. В первую очередь это свойство помогает вам, чтобы вы случайно не удалили что-то лишнее и не спровоцировали дополнительные проблемы и хлопоты.
Разберем ситуацию на практике. К примеру, вы занимаетесь координацией грузоперевозок. Для этого вы создали несколько таблиц в базе данных, например «Грузоперевозчики» и «Заказы на перевозку». То есть большая вероятность, что один ваш грузоперевозчик своими несколькими машинами может обслуживать сразу несколько заказов из таблицы «Заказы на перевозку», то есть задействовано правило «один на несколько». Прошло какое-то время, вы хотите перестать сотрудничать с грузоперевозчиком и вам, соответственно, нужно удалить его из таблицы «Грузоперевозчики». Но если у этого грузоперевозчика есть активные заказы из таблицы «Заказы на перевозку», то они, в случае его удаления, станут «потерянными» записями, так как ID грузоперевозчика станет недействительным, потому что записи с этим ID больше не существует. А если таких записей много? А если таких грузоперевозчиков много? Тогда в ваших таблицах будет полнейший бардак. Но ситуацию выручает обеспечение целостности данных в Access. Данное свойство просто не даст вам удалить грузоперевозчика, пока у него есть активные заказы в другой таблице.
СОДЕРЖАНИЕ
Типы целостности
Физическая целостность
Логическая целостность
Как физическая, так и логическая целостность часто имеют много общих проблем, таких как человеческие ошибки и недостатки проектирования, и оба должны соответствующим образом обрабатывать параллельные запросы на запись и извлечение данных, последний из которых является полностью самостоятельной темой.
Если в секторе данных есть только логическая ошибка, его можно использовать повторно, перезаписав его новыми данными. В случае физической ошибки затронутый сектор данных навсегда становится непригодным для использования.
Базы данных
Типы ограничений целостности
Целостность данных обычно обеспечивается в системе баз данных с помощью ряда ограничений или правил целостности. Три типа ограничений целостности являются неотъемлемой частью реляционной модели данных: целостность объекта, ссылочная целостность и целостность домена.
Если база данных поддерживает эти функции, она несет ответственность за обеспечение целостности данных, а также за модель согласованности для хранения и извлечения данных. Если база данных не поддерживает эти функции, приложения несут ответственность за обеспечение целостности данных, в то время как база данных поддерживает модель согласованности для хранения и поиска данных.
Наличие единой, хорошо контролируемой и четко определенной системы целостности данных увеличивает
Современные базы данных поддерживают эти функции (см. Сравнение систем управления реляционными базами данных ), и де-факто ответственность за обеспечение целостности данных стала возложена на базу данных. Компании и многие системы баз данных предлагают продукты и услуги для переноса устаревших систем на современные базы данных.
Примеры
Примером механизма целостности данных являются отношения между родителями и потомками связанных записей. Если родительская запись владеет одной или несколькими связанными дочерними записями, все процессы ссылочной целостности обрабатываются самой базой данных, что автоматически обеспечивает точность и целостность данных, так что ни одна дочерняя запись не может существовать без родительской записи (также называемой осиротевшей) и что ни один родитель не теряет свои дочерние записи. Это также гарантирует, что никакая родительская запись не может быть удалена, пока родительская запись владеет какими-либо дочерними записями. Все это обрабатывается на уровне базы данных и не требует проверки целостности кода в каждом приложении.
Файловые системы
Запросы модификации данных
Введение в понятие «целостность данных»
В базе данных, построенной на реляционной модели, задается ряд правил целостности, которые, по сути, являются ограничениями для всех допустимых состояний базы данных и гарантируют корректность данных. Рассмотрим следующие типы ограничений целостности данных :
Обязательные данные
Некоторые поля всегда должны содержать одно из допустимых значений, другими словами, эти поля не могут иметь пустого значения.
Ограничения для доменов полей
Каждое поле имеет свой домен, представляющий собой набор его допустимых значений.
Корпоративные ограничения целостности
Целостность сущностей
Это ограничение целостности касается первичных ключей базовых таблиц. По определению, первичный ключ – минимальный идентификатор (одно или несколько полей), который используется для уникальной идентификации записей в таблице. Таким образом, никакое подмножество первичного ключа не может быть достаточным для уникальной идентификации записей.
Ссылочная целостность
Существует три разновидности связи между таблицами базы данных:
Связь «один-ко-многим» наиболее распространена для реляционных баз данных. Она позволяет моделировать также иерархические структуры данных.
Отношение «многие-ко-многим» имеет место в следующих случаях:
Считается, что всякая связь «многие-ко-многим» может быть заменена на связь «один-ко-многим» (одну или несколько).
Следующая проблема связана с организацией поддержки ссылочной целостности при выполнении операций модификации данных в базе. Здесь возможны следующие ситуации:
Существует и другой вид целостности – смысловая (семантическая) целостность базы данных. Требование смысловой целостности определяет, что данные в базе данных должны изменяться таким образом, чтобы не нарушалась сложившаяся между ними смысловая связь.
Уровень поддержания целостности данных в разных системах существенно варьируется.
Идеология архитектуры клиент-сервер требует переноса максимально возможного числа правил целостности данных на сервер. К преимуществам такого подхода относятся:
К недостаткам хранения ограничений целостности на сервере можно отнести:
На практике в клиентских приложениях реализуют лишь такие правила, которые тяжело или невозможно реализовать с применением средств сервера. Все остальные ограничения целостности данных переносятся на сервер.
Как проверить целостность данных: чек-лист
В современном мире информация является не менее ценной, чем золото или нефть. Она перемещается и является катализатором многих процессов в глобальной экономике. Как нельзя лучше это иллюстрируют появляющиеся сегодня термины, например, “Big Data”. И точно так же, как золото или нефть, информация нуждается в защите, поэтому сохранение целостности данных стало важной задачей любого IT- отдела.
Определение целостности данных
В эпоху Интернета, этот термин стал прочно ассоциироваться с серверами и базами данных, которые уже могут размещаться в облаке и являются основными хранилищами информации.
У целостности данных есть 3 измерения:
Например, передача данных покупателя из формы подписки в базу данных CRM.
Например, хранение данных о кредитной карте покупателя на сервере интернет-магазина.
Особенно это важно для компаний, работающих с наиболее важной информацией, например, для банковских систем или медицинских организаций.
Что может нарушить целостность данных и как справляться с последствиями
Существует множество причин нарушения целостности информации, но все их можно условно разделить на 2 группы:
С момента появления Интернета, хакеры пытались быстро и без усилий заработать, используя любые доступные уязвимости.
Исследования показали, что бренды компаний, которые стали жертвами взлома, резко теряют популярность и доверие покупателей. 15% всех опрошенных ответили, что прекратят любое взаимодействие с компанией, если она станет жертвой взлома, еще 13% заявили, что никогда не будут сотрудничать с подобной компанией.
Целостность данных важна не только с точки зрения целей бизнеса, но и для соответствия законодательству.
В России, США и странах Евросоюза существуют законодательные нормы для компаний, работающих с данными покупателей, за нарушение которых положены крупные штрафы.
Обучение персонала
Практически все данные в компании проходят через руки её сотрудников. Именно они в первую очередь ответственны за верификацию данных, поэтому с них должна начинаться любая политика безопасности в компании.
Во-первых, обмен данными внутри компании должен быть четко регламентирован. Это позволит избежать ситуаций, когда сотрудники одного отдела (например, контроля качества) могут просматривать и изменять данные, необходимые для работы другого отдела(например, отдела продаж).
Если в рамках рабочего процесса сотрудники должны обмениваться аккаунтами, предусмотрите временные пароли или менеджеры паролей (например, Enterprise Password Vault от CyberArk). Это позволит обеспечить обмен аккаунтами, при этом не давая доступа к паролям.
Во-вторых, персонал компании должен внимательно относиться к данным, и сообщать о любой подозрительной активности. Признаков определения взлома системы достаточно много, но чаще всего на них долго не обращают внимания. Такими признаками являются, например, изменённые пароли, пропажа файлов, активность аккаунта в неположенное время, несанкционированные изменения в файлах.
Шифрование
Шифрование является прекрасным способом защиты данных компании, но его эффективность ограничена, и оно значительно снижает производительность.
Шифрование данных позволяет обеспечить их безопасность даже в случае физической кражи носителя, поэтому, если риск попадания данных в чужие руки велик, этим методом нельзя пренебрегать.
В некоторых случаях, однако, шифрование бесполезно. Например, если злоумышленник для получения доступа к файлам использует данные одного из сотрудников организации. Именно поэтому нельзя ограничивать информационную защиту только средствами шифрования.
Отслеживание метаданных
Важно понимать, что метаданные могут быть интересны и злоумышленникам, так как в них могут содержаться сведения типе операционной системы, версиях и паролях программ, а также адреса электронной почты сотрудников.
Ограничение физического доступа к оборудованию
Часто возникает ситуация, когда для кражи данных злоумышленнику достаточно просто скопировать их на флешку с компьютера или сервера. Именно поэтому на любом предприятии доступ к серверам и базам данных должен быть только у определённых сертифицированных специалистов.
Наиболее важные устройства, например, серверы, должны находиться в отдельных закрытых комнатах с соответствующей вентиляцией для охлаждения, а в идеале должны быть прикреплены к полу, чтобы исключить возможность физического хищения.
Такие меры могут усложнить работу системным администраторам, но безопасность данных должна являться приоритетом.
Если компания ограничена в свободном пространстве, то серверы и базы данных должны находиться под постоянным наблюдением сотрудника, которым, в зависимости от структуры компании, может быть системный администратор или менеджер.
Резервное копирование данных
По иронии, некоторые компании становилась жертвами взлома именно из-за наличия резервной копии. Известны случаи, когда незащищенную копию данных компании можно было просто найти в поисковой системе.
Если резервная копия попадет не в те руки, извлечь из неё данные может быть достаточно просто.
Поиск и удаление дубликатов
В процессе работы компании часто возникает ситуация, когда важная информация копируется и хранится в папках с общим доступом или в сторонних облачных хранилищах.
Чтобы избежать попадания данных в руки преступников, важно регулярно проводить поиск и удалять дубликаты файлов. Это можно делать вручную или использовать различные программные решения.
SSL шифрование
Наличие SSL-протокола — это черта любого уважающего себя сайта. Он позволяет шифровать данные, которые передаются между клиентом и сервером, в результате чего существенно снижается риск их попадания в руки третьих лиц.
Стоимость такого сертификата невелика, поэтому любая компания должна приобрести его как можно быстрее.
Стресс-тесты
Для атаки на серверы злоумышленники часто перегружают их, заставляя обрабатывать слишком большие объемы информации. Даже без действий злоумышленников, у любого сервера есть предел вычислительной мощности, поэтому важно регулярно проводить стресс-тесты, чтобы проверять состояние сервера и его надежность в экстренной ситуации.
Security аудит
Самый лучший способ проверить безопасность данных — это провести тест в “полевых условиях”. Примерная схема заключается в том, что человек, владеющий “хакерскими” навыками должен попытаться получить доступ к системе, после чего предоставить отчет об обнаруженных уязвимостях.
В крупных компаниях такой человек может быть штатным специалистом, малый бизнес традиционно отдает эту задачу на аутсорсинг.
Существует также специальное ПО (например, Rapid7), предназначенное для проведения полного аудита инфраструктуры компании.
В рамках аудита вы должны получить ответы на вопросы:
Отслеживание изменений
Для безопасности данных важно отслеживать источники атак. Специальное ПО, предназначенное для этого, позволяет:
Информация — это основа современной экономики, поэтому её защита от посторонних глаз важна для любой компании. Методы, описанные в этой статье, должны применяться на любом предприятии. Позаботьтесь о безопасности своих данных сегодня!
Целостность данных в микросервисной архитектуре — как её обеспечить без распределенных транзакций и жёсткой связности
Всем привет. Как вы, возможно, знаете, раньше я все больше писал и рассказывал про хранилища, Vertica, хранилища больших данных и прочие аналитические вещи. Сейчас в область моей ответственности упали и все остальные базы, не только аналитические, но и OLTP (PostgreSQL), и NOSQL (MongoDB, Redis, Tarantool).
Эта ситуация позволила мне взглянуть на организацию, имеющую несколько баз данных, как на организацию, имеющую одну распределенную гетерогенную (разнородную) базу. Единую распределенную гетерогенную базу, состоящую из кучи PostgreSQL, Redis-ов и Монг… И, возможно, из одной-двух баз Vertica.
Работа этой единой распределенной базы порождает кучу интересных задач. Прежде всего, с точки зрения бизнеса важно, чтобы с данными, движущимися по такой базе, все было нормально. Я специально не использую здесь термин целостность, consistency, т.к. термин это сложный, и в разных нюансах рассмотрения СУБД (ACID и CAP теорема) он имеет разный смысл.
Ситуация с распределенной базой обостряется, если компания пытается перейти на микросервисную архитектуру. Под катом я рассказываю, как обеспечить целостность данных в микросервисной архитектуре без распределенных транзакций и жесткой связности. (А в самом конце объясняю, почему выбрал для статьи такую иллюстрацию).
Согласно Крису Ричардсону (одному из известнейших евангелистов микросервисной архитектуры), в этой архитектуре есть два подхода к работе с базами данных: shared database и database-per-service.
Shared database — это неплохой первый шаг, отличное решение для небольшой компании без амбициозных планов роста. При этом сам по себе этот паттерн является анти-паттерном с точки зрения микросервисной архитектуры, т.к. два сервиса, делящих общую базу, нельзя независимо тестировать и масштабировать. Т.е. эти сервисы скорее — один сервис, тяготеющий к превращению в монолит.
Паттерн database-per-service предполагает, что у каждого сервиса своя база. Сервис может обращаться к данным другого сервиса только через API (в широком смысле), без прямого подключения к его базе.
Паттерн database-per-service позволяет командам соответствующих сервисов выбирать базы, как им нравится. Кто-то умеет в MongoDB, кто-то верит в PostgreSQL, кому-то достаточно Redis (риск потери данных при выключении для этого сервиса приемлем), а кто-то вообще хранит данные в CSV-файлах на диске (а почему бы, собственно, и нет?).
Работа с подобным «зоопарком» баз данных поднимает задачу наведения порядка в данных на абсолютно новый уровень сложности.
ACID и микросервисная архитектура
Давайте посмотрим на задачу наведения порядка через призму классического СУБД-шного набора требований ACID: развернем суть каждой буквы аббревиатуры, и проиллюстрируем сложности с этой буквой в микросервисной архитектуре.
(A) CID — Atomicity. Atomicity — все или ничего.
Согласно требованию Atomicity, нужно обязательно выполнить все шаги (с возможными повторами), при отказе важного шага — отменить выполнившиеся.
В приведенной иллюстрации демонстрируется тестовый процесс покупки услуги VIP: резервируются деньги в биллинге (1), для пользователя подключается бонусная услуга (2), тип пользователя меняется на Pro (3), зарезервированные деньги в биллинге списываются (4). Все четыре шага должны либо выполниться, либо не выполниться.
При этом нельзя зависнуть посередине процесса, поэтому предпочтительнее асинхронность, в крайнем случае — синхронность со встроенным таймаутом.
A(С)ID – Consistency. Consistency – каждый шаг не должен противоречить граничным условиям.
Классические примеры условий для, например, отправки денег от клиента А в сервисе 1 клиенту B в сервисе 2: в результате подобной отправки денег не должно стать меньше (деньги при пересылке не должны пропасть) или больше (недопустимо отправить одни и те же деньги двум пользователям одновременно). Для соблюдения этого требования нужно где-то кодировать условия и проверять данные для условий (в идеале — без дополнительных обращений).
ACI(D) — Durability. Требование Durability означает, что последствия операций не пропадают.
В условиях Polyglot persistence сервис может работать на базе данных, которая штатно может «потерять» записанные в нее данные. Подобный фокус можно получить даже от солидных баз наподобие PostgreSQL, если там включена асинхронная репликация. На иллюстрации демонстрируется, как изменения, записанные в Master, но не доехавшие в Slave по асинхронной репликации, могут быть уничтожены сгоранием сервера Master. Для обеспечения требования Durability требуется уметь штатно диагностировать и восстанавливать подобные потери.
А где же I, спросите вы?
А нигде. Изоляция в среде нескольких независимых асинхронных сервисов — это техническое требование. Современные исследования показали, что реальные бизнес-процессы можно реализовывать без изоляции. Изоляция упрощает мышление тем, что минимизирует параллелизм (разработка параллельных вычислений сложнее для программиста), но микросервисная архитектура по своей сути массивно-параллельная, изоляция в такой среде избыточна.
Существует много подходов, позволяющих добиться соблюдения перечисленных выше требований. Наиболее широко известен алгоритм распределенных транзакций, обеспечиваемых так называемым двухфазным коммитом (2PC). К сожалению, реализация двухфазных коммитов требует переписывания всех вовлеченных сервисов. И самое серьезное: этот алгоритм не очень производителен. Приведенные иллюстрации из недавних исследований показывают, что этот алгоритм показывает определенную производительность на распределенной базе из двух серверов, но при росте количества серверов производительность растет не линейно… А точнее, практически совсем не растет.
Одно из главных достоинств микросервисной архитектуры — возможность около линейно наращивать производительность, просто добавляя больше и больше серверов. Получается, что если для обеспечения распределенной целостности использовать двухфазный коммит, то этот процесс станет узким местом, ограничителем для роста производительности, несмотря на наращивание количества серверов.
Как же можно обеспечить распределенную целостность (требования ACiD) без двухфазных коммитов, с возможностью линейно масштабироваться по производительности?
Современные исследования (например, An Evaluation of Distributed Concurrency Control. VLDB 2017) утверждают, что помочь может так называемый «оптимистический подход». Разницу между двухфазным коммитом и обобщенным «оптимистическим подходом» можно проиллюстрировать разницей между старым советским магазином (с прилавком), и современным супермаркетом, вроде Ашана. В магазине с прилавком каждый покупатель считается подозрительным, и обслуживается с максимальным контролем. Отсюда очереди и конфликты. А в супермаркете покупатель по умолчанию считается честным, ему дают возможность самому подходить к полкам и набивать тележки. Конечно, есть средства мониторинга для ловли жуликов (камеры, охрана), но большинству покупателей никогда не приходится с ними сталкиваться.
Поэтому супермаркет можно масштабировать, расширять, просто ставя больше касс. Аналогично и с микросервисной архитектурой: если распределенная целостность обеспечивается «оптимистическим подходом», когда дополнительно нагружаются проверками только процессы, где что-то пошло не так. А нормальные процессы идут без дополнительных проверок.
Важно. К «оптимистическому подходу» относится несколько алгоритмов. Я хотел бы рассказать вам про сагу — алгоритм поддержания распределенной целостности, рекомендуемый Крисом Ричардсоном.
Саги — элементы алгоритма
Алгоритм саг имеет два варианта. Поэтому сначала я хотел бы универсально описать требуемые элементы алгоритма, чтобы описание подходило для обоих вариантов.
Элемент 1. Надежный персистентный канал доставки событий между сервисами, гарантирующий «at least once delivery». Т.е. если шаг 2 процесса успешно завершился, то извещение (событие) об этом должно достигнуть шага 3 как минимум однажды, повторные доставки допустимы, но потеряться ничего не должно. «Персистентный» означает, что канал должен хранить извещения какое-то время (2-3 дня, неделю), чтобы сервис, потерявший последние изменения из-за потери базы (см. пример про Durability, на иллюстрации это шаг 2), мог восстановить эти изменения, «перепроиграв» события из канала.
Элемент 2. Идемпотентность вызовов сервисов за счет использования уникального ключа идемпотентности. Представим, что я (пользователь) инициирую процесс покупки VIP-пакета (см. пример для Atomicity). В начале процесса мне выдается уникальный ключ, ключ идемпотентности, например, 42. Далее вызов каждого из шагов (1→2→3→4) должен выполняться с указанием ключа идемпотентности. В пункте выше упоминается возможность повторного прихода одинакового сообщения в сервис (в шаг). Сервис (шаг) должен автоматически уметь игнорировать повторный приход обработанного события, проверяя повторность по ключу идемпотентности. Т.е., если все сервисы (шаги процессов) идемпотентные, то для обеспечения требований Atomicity и Durability достаточно переотправить в шаги, соответствующие событиям из каналов. Шаги, пропустившие события, выполнят их, а шаги, уже выполнившие события, проигнорируют их из-за идемпотентности.
Элемент 3. Отменяемость вызовов сервисов (шагов) по ключу идемпотентности.
Для обеспечения Atomicity (см. пример), если процесс с ключем идемпотентности 42, например, остановился/упал на шаге 3, то необходимо отменить успешные выполнения шагов 1 и 2 для ключа 42. Для этого каждый обязательный шаг процесса должен обладать «компенсирующим» шагом, API-методом, отменяющим выполнение обязательного шага для указанного ключа идемпотентности (42). Реализация компенсирующих вызовов — это тяжелый, но необходимый элемент доработки сервисов в рамках внедрения алгоритма саг.
Перечисленные выше три элемента актуальны для обоих вариантов реализации «cаг»: оркестрируемых и хореографических.
Оркестрируемые саги
Более простой и очевидный алгоритм оркестрируемых саг проще для понимания и реализации. В своей отличной статье kevteev описал алгоритм и процесс реализации механизма оркестрируемых саг в Авито. Их алгоритм предполагает существование контролирующего сервиса, «оркестрирующего» вызовы сервисов в рамках обслуживаемых бизнес-процессов. Этот же контролирующий сервис может обладать собственной базой данных (например, PostgreSQL), выступающей в роли надежного персистентного канала доставки событий (элемент 1).
Хореографические саги
С хореографической сагой хитрее. Тут в качестве надежного персистентного канала должна выступать шина данных, реализующая следующие требования: fire-and-forget publishing, publish-subscribe event delivery, at least once delivery. Т.е. каждый шаг каждого процесса должен получать команду на срабатывание из шины, и кидать туда же сообщение об успешном выполнении, о старте следующего шага, чтобы тот тоже прочитал его из шины и продолжил выполнение процесса. При этом на каждое сообщение может быть несколько подписчиков.
В хореографической саге тоже должен быть контролирующий сервис, сервис саг, но существенно более «легковесный». Сервис должен знать о зарегистрированных в системе бизнес-процессах, о составе входящих в каждый процесс шагов. Также он должен слушать шину, мониторить выполнение каждого процесса (каждого ключа идемпотентности), и, только если что-то пошло не так, либо кидать «повторы» конкретных шагов, либо кидать «отмены», «компенсации» для выполнившихся шагов.
Нюансы
Один из самых важных нюансов саг, отличающих их от классических транзакций, является отход от линейности, последовательности, обязательности каждого шага. Сага — это не обязательно линейная цепочка событий, этом может быть направленный граф: событие регистрации нового пользователя может породить несколько шагов в параллель (отправка смс, регистрация логина, генерация пароля, отправка письма), часть из которых может являться необязательными. В первом приближении кажется, что в подобной «разветвленной» саге с необязательными шагами тяжело определить завершение саги (процесса), но, на самом деле, все просто: сага (процесс) завершена, когда завершены все обязательные шаги, в любом порядке.
Второй нюанс, характерный скорее для хореографических саг, но возможный и для оркестрируемых, заключается в выборе подхода к регистрации бизнес-процессов, типов саг в сервисе саг. В примере для Atomicity описан процесс из четырех последовательных обязательных шагов.
Кто зарегистрировал этот процесс, указал все шаги, расставил зависимости и обязательность шагов? Очевидный, но старомодный ответ заключается в том, что регистрация процесса должна выполняться централизованно, в сервисе саг. Но этот ответ не очень соответствует микросервисной архитектуре. В микросервисной архитектуре более перспективно, более производительно и более быстро регистрировать процессы «снизу вверх». Т.е. не прописывать все нюансы процесса в сервисе саг, а дать возможность отдельным сервисам самостоятельно «вписываться» в существующие процессы, указывая свою обязательность/необязательность и обязательных предшественников.
Т.е. процесс регистрации пользователя в сервисе саг может изначально состоять из трёх шагов, а потом, в ходе развития системы, туда впишутся еще семь шагов, а один шаг выпишется, и их станет девять. Подобная «анархическая» и «децентрализованная» схема сложна для тестирования, для реализации строгого согласованного процесса, но она намного удобнее для Agile команд, для непрерывной разнонаправленной эволюции продукта.
Собственно вот. С серьезным изложением, думаю, стоит закончить, а то статья получилась слишком большая.
Вот ссылка на презентацию этого материала, доклад на эту тему я делал на Highload Siberia 2018.
UPD — и видео с конференции:
Эпилог
Напоследок хотел бы попробовать объяснить все, перечисленное выше, более образным языком.
Ведь что такое сага изначально? Это сюжет, это приключение из средних веков… Или из Игры Престолов. Происходит событие (битва, свадьба, кто-то умирает), весть об этом летит по миру через гонцов, через почтовых голубей, через купцов. Когда весть доходит до заинтересованных (через неделю, через месяц, через год), они реагируют: отправляют армии, объявляют войну, кого-то казнят, и летят новые вести.
Нет контролирующего органа, следящего за последовательностью действий. Нет транзакций, нет rollback, в смысле отмены действия, как будто его никогда не было. Все по-взрослому, каждое действие происходит навсегда. Его можно компенсировать, но это именно действие (убийство) и компенсация (плата за голову, вира), а не отмена смерти.
События идут долго, доходят из разных источников, действия происходят параллельно, а не строго последовательно. И довольно часто в сюжете внезапно возникают новые участники, решившие поучаствовать (прилетают драконы ;))… а кое-кто из старых участников внезапно умирает.
Такие дела. Вроде бардак и хаос, но все работает, внутренняя согласованность мира не нарушается, сюжет развивается и непротиворечив… Хотя иногда и непредсказуем.