Прямой ответ
Каждому решению назначают постоянный идентификатор и неизменяемую версию. Создание, вступление в силу, приостановление, отзыв, исправление, истечение срока и замена хранятся как добавляемые события без стирания прежней записи. В каждом событии есть идентификатор события, время, участник, полномочие, причина, предыдущее и новое состояния, доказательство и целевая версия. Текущее состояние вычисляется по этим уполномоченным событиям, а не подменяет их историю.
Простыми словами
Представьте банковскую выписку. Сегодняшний остаток показан одним числом, но все поступления и списания сохранены, поэтому видно, как он получился. Текущее состояние решения так же рассчитывается по истории событий.
Почему это важно
Перезапись одного поля статуса уничтожает доказательства того, кто, когда и почему изменил решение. Тогда система может принять старое, приостановленное или отозванное решение за действующее.
Не путать
- Идентификатор решения обозначает одно семейство решения; идентификатор версии — конкретное содержание.
- Событие фиксирует уполномоченное изменение состояния решения.
- Текущее состояние — представление, вычисленное по событиям; история событий — цепочка доказательств.
- Исправление устраняет неточное содержание; замена показывает, что новое решение заняло место прежнего.
- Приостановление — временное операционное состояние; отзыв — уполномоченное прекращение действия решения.
Что делать
- Определите постоянный идентификатор решения, неизменяемый идентификатор версии и явную схему.
- Записывайте каждое изменение жизненного цикла отдельным идентификатором события и надёжной временной меткой.
- Сделайте обязательными поля участника, роли, полномочия, причины, доказательства, прежнего и нового состояний.
- Задайте допустимые переходы состояний и блокируйте недопустимые машиночитаемыми правилами.
- Связывайте исправление, отзыв и замену в обе стороны, не удаляя прежнюю версию.
- Формируйте и пересчитывайте вид текущего состояния из потока событий по однозначным правилам.
- Передавайте событие в нижестоящие системы и добавляйте к решению доказательства доставки, применения и обратного считывания.
Как проверить
- Уникальны, постоянны и версионированы ли идентификаторы решения и событий?
- Не перезаписано ли прежнее содержание решения или событие?
- Содержит ли каждое событие время, участника, полномочие, причину и доказательство?
- Блокируются ли недопустимые или неуполномоченные переходы?
- Прослеживаются ли связи исправления, отзыва и замены в обе стороны?
- Можно ли заново получить текущее состояние из сохранённых событий?
- Достигли ли нижестоящие системы того же текущего состояния?
Ограничение
Добавление событий без перезаписи усиливает неизменность и прослеживаемость, но само по себе не доказывает фактическую правильность или правомерность события. Нужны также надёжные средства времени, идентификации, полномочий и целостности.
Запомните одной фразой
Текущее состояние не стирает прошлое; оно возникает из уполномоченных событий этого прошлого.
Источники этой записи
- S14DataCite, *Versioning*Инфраструктура идентификации
- S15DataCite, *Connecting Versions with Related Identifiers*Инфраструктура идентификации
- S26NIST SP 800-53 Rev. 5, *Security and Privacy Controls*Стандарты
- S35W3C, *PROV-O: The PROV Ontology*Стандарты
- S36W3C, *Trace Context*Стандарты
- S37OpenTelemetry, *General Trace Semantic Conventions*Стандартная и проектная документация