Каждое утро понедельника инженерное руководство задает один и тот же утомительный вопрос: «Как нам сделать нашу систему соответствующей требованиям?» Рефлекторная реакция почти всегда состоит в том, чтобы запустить еще один спринт, написать общую оболочку промежуточного программного обеспечения и привязать к нему стороннюю...
Почему еще один аудит разрушит вашу архитектуру
Каждое утро понедельника инженерное руководство задает один и тот же утомительный вопрос: «Как нам сделать нашу систему соответствующей требованиям?» Рефлекторная реакция почти всегда состоит в том, чтобы запустить еще один спринт, написать общую оболочку промежуточного программного обеспечения и подключить сторонний регистратор аудита на периферии. Мы относимся к соблюдению требований и управлению как к запоздалому слою краски — к чему-то, что вы наносите на разрушающуюся конструкцию в надежде, что инспектор не присмотрится слишком внимательно. Но вот жестокая правда: еще один аудит не является основой для принятия решения. Это дорогостоящая иллюзия безопасности, которая незаметно разрушает вашу основную бизнес-логику.
Проблема, которую все игнорируют
Если вы рассматриваете аудит как последующий сборщик событий, а не как неизменяемую часть вашего конечного автомата, все в конечном итоге разваливается. В конечном итоге вы получаете асинхронных отправителей журналов, пытающихся восстановить сложные распределенные транзакции из беспорядочных, разделенных блоков JSON. Хуже того, вы создаете систему, в которой логика приложения может выполнять изменение состояния без постоянной привязки сопутствующего контекста решения к этому состоянию.
Вспомните, когда в последний раз одитор просил вас доказать, почему