Привет, Хабр. В этой статье я хочу начать рассказ об одном из самых масштабных и интересных проектов, к разработке которого привлечена моя команда - ECM-системе, которую мы создаем от этапа концепта до непосредственно вывода ее в промышленную эксплуатацию. Расскажу о назначении этой системы, предпосылках ее появления, причинах выбора пути самостоятельной разработки вместо покупки готового решения, проектировании этой системы, процессе ее разработки и многом другом.
Предметная область
Наш банк ежедневно генерирует огромное количество бумажных документов, причем самого разнообразного вида. И должен где-то их хранить. Но не просто положить куда-то стопку бумаг и забыть - необходимо точно знать, что и где лежит. А лучше всего - каталогизировать хранение так, чтобы можно было получить копию документа, зная о нем только базовую или обрывочную информацию. Для этой цели у нас существуют отдельные службы, которые принимают бумагу от всех структурных подразделений банка, размещают ее в хранилище, сканируют по необходимости и отдают обратно по запросу.
Бумага это всего лишь физический носитель информации, тогда как львиная доля документации уже давно электронная - и многие банковские процессы даже не требуют делать бумажную копию. Например, специалист в офисе может отсканировать предоставленный клиентом документ и запустить на его базе процессы обслуживания. Для таких сканов требуется во-первых фиксация их равнозначности бумажной версии - условная отметка “Копия верна”. А во-вторых, они должны не только храниться, занимая место, но и по возможности переиспользоваться без дупликации. А значит, нужно уметь искать эти копии в хранилище по набору атрибутов, с коррекцией ошибки. И предоставлять функционал валидации уже имеющегося документа, либо его версионирования.
Здесь можно привести пример, когда клиент, будучи, например, на Дальнем Востоке, обращается в отделение банка, предоставляет паспорт и получает услугу. А через два месяца он уже на Юге, у него изменилось место регистрации, и он хочет получить уже другую услугу. Кардинально его паспорт не поменялся, но частично изменилось его наполнение, а значит, нам нужно зафиксировать этот факт в наших данных. А если данные не поменялись, то нам достаточно сверить то, что мы уже имеем, с тем, что принес клиент, и не тратить время на повторение процесса приема всех документов.
Далее, каждое взаимодействие клиента с банком влечет явную или неявную генерацию заявления - банк не имеет юридического права делать что-то без фиксации на это согласия клиента. Заявление может быть как лично написано и подписано клиентом, так и быть представлено в электронном виде и подписано электронной подписью. В зависимости от значимости документа подпись может быть простой или должна быть квалифицированной. Если с бумажной формой все предельно ясно, то безотносительно вида электронного документа мы обязаны хранить его в том виде, в котором он был создан и иметь возможность проверить корректность подписи в любой момент. И предоставить электронный образ с визуализированной подписью по требованию.
Резюмируя, нам необходимо:
хранить документы в бумажном виде
хранить документы в электронном виде
уметь переводить первое во второе
уметь искать и первые, и вторые, не зная точно содержимое
уметь хранить долгосрочно и обеспечивать юридическую значимость
Синхронизируем терминологию
Enterprise content management (ECM) - системы управления контентом масштаба предприятия. Они хранят, доставляют и управляют данными о документах. Это не только информация о месте хранения и цифровая копия, но и извлеченные и распознанные бизнес-атрибуты, состав которых разный для разных типов документов. Кроме того, такие системы должны обеспечивать извлечение и быструю доставку по переменному составу поисковых критериев и их нечеткой формализации. Условно, нужно иметь возможность быстро найти документ, помещенный в хранилище десяток лет назад, по фамилию, из которой известны только первые три буквы.
В российском ИТ под термином “Enterprise” часто ошибочно понимают предприятие любого размера, и необходимость в отдельной системе такого класса размывается и становится совершенно неочевидной. Но если условной фирме с десятком человек, такая система вероятно будет лишней, то федеральному банку без нее точно не прожить. Поэтому сразу стоит указать на отличия ECM системы от СЭД и CMS.
Content management system (CMS) - это зачастую системы, направленные на создание либо совместный доступ к ограниченному по объему контенту. Редко когда у них есть сложные, многослойные хранилища. ECM при этом практически не имеет внешних интерфейсов, потому как является чисто бэковской системой. При этом обладает широкими возможностями по интеграции, в том числе путем встраивания в интерфейсы других систем.
Системы электронного документооборота (СЭД) же направлены скорее на внешнюю работу с документом - там вторично, что оборачивается, а важно как именно. Тогда как ECM может содержать какой-то набор действий, срабатывающий в ответ на получение документа, но не содержит в себе процессов, которые выходят за границы простой обработки документа. Например, поручения провести распознавание документа или отреагировать на его появление выставлением счета в сторонней системе.
Важная особенность ECM-систем состоит также в том, что они большое внимание уделяют защите данных - документы версионируются, доступ к ним разграничивается относительно пользователя и его роли. Документы должны не утрачивать со временем свою юридическую значимость - для этого имплементируются специальные системы, обеспечивающие эту значимость - например, путем вторичного наложения подписи при извлечении.
Документы, которые поступают на хранение, нужно оцифровать и провести через процедуру извлечения из них данных, поэтому необходимо подключить системы сканирования, поддерживающие конвейерную обработку документов. Кроме того, документ должен быть проверен на уникальность, чтобы исключить повторную загрузку. ECM становятся еще и системами хранения знаний - при накоплении контента данные приобретают все большую связанность. Это позволяет формировать детальную картину отношений банка с клиентом или сотрудником. И в конечном счете использовать эти знания для более таргетированного предложения новых услуг.
Текущее состояние и предпосылки замены
Итак, для автоматизации работы с документами мы внедрили систему, которая обеспечивает достаточно неплохой уровень работы именно с бумажным хранилищем, каталогизацией и всеми процессами, связанными с размещением. Но в силу своей узкой направленности, при росте количества электронного контента, эта система начала выполнять все более неспецифичные для нее функции.
Дополнительно на это наложились внешние обстоятельства в виде удорожания лицензий на программные продукты, входящие в состав комплекса: стоимость владения и развития начала быстро расти, усложнилось сопровождение. Простая экстраполяция показала, что через несколько лет система просто развалится под собственным весом - уже сейчас ее перезапуск влечет за собой несколько часов простоя.
Провести рефакторинг этой системы уже невозможно, так как подходящий для этого момент был упущен - потенциальные затраты на него превысили возможную выгоду. Кроме того, каркас системы заказывался сторонней компании. Значит необходимо стало заменить ее на что-то новое. Беглый анализ рынка показал, что готовых решений, которые можно было бы с допустимым размером затрат адаптировать под наши нужды попросту нет.
Мы решили сделать такую систему самостоятельно, построив ее на базе современных подходов к проектированию и разработке. И по большей части на базе свободно распространяемого ПО с открытым исходным кодом. Провести импортозамещение, одним словом.
Приступаем к проектированию
Начнем более глубокий анализ предметной области и проведем декомпозицию. Мы имеем документы разных типов, с разной структурой, на разных носителях, с разным местом хранения, с разными связями и которые должны иметь историю изменений.
Для их описания введем сущность “Документ”. Она будет обладать набором атрибутов - полей, которые условно можно разделить на три большие группы:
бизнес-поля: всё, что имеет прямое или косвенное отношение к внутреннему наполнению документа: различные номера, даты, имена клиентов.
системные поля: здесь мы подразумеваем различные метаданные по телу сущности - файлу, размеру, виду; сюда же относятся данные по создателю документа, различным отметками времени. Сюда же можно отнести связи одной сущности с другими (например, договор - паспорт клиента);
интеграционные: поля, необходимые в процессах предоставления контента внешним системам.
Описывая сущность, сразу отделим тело сущности - файл - и будем рассматривать его как системное поле, содержащее ссылку на точку хранения. При этом, учитывая версионность тела, предусмотрим возможность хранить несколько ссылок. Так как версионность может иметь не только файл, а весь документ целиком, то в системных полях файла добавим атрибут “номер версии”, характеризующий конкретную копию объекта, и глобальный идентификатор сущности, который един для всех версий документа.
Каждая сущность может быть связана с другой сущностью или набором сущностей. Но при этом связываться сущности могут как по глобальному идентификатору, так и по локальному идентификатору версии объекта. Например, кредитный договор, прямо связан с паспортом клиента, который его заключил, при этом по условиям договора клиент обязан предоставлять в банк обновленный документ, если происходят какие-то действия. То есть связь идет: договор - паспорт, вне зависимости от версии последнего. Аналогично, может существовать связка с конкретной версией документа, скажем, какого-нибудь плана или технической документацией.
Связи между сущностями могут быть как односторонними, так и двухсторонними. В нашем примере - паспорт явно подчиненная сущность, связь имеет направление “от договора”. А могут быть и равноценными. В итоге у нас получается примерно такая структуру объектов и отношений между ними:
Описывая сами объекты в дальнейшем, будем руководствоваться принципами предметно-ориентированного проектирования (domain-driven design, DDD). Обобщенно - мы будем моделировать каждый участок предметной области как независимый от других областей - доменов, и описывать в нем структуру объекта и всю логику работы с ним (например, установку связей с другими объектами и доменами). При дальнейшем описании системы и объектов будем оперировать понятием “домен”, как группы связанных сущностей с единой логикой обработки.
Программная архитектура системы
При наполнении данными и функционалом текущая система стала все хуже реагировать на каждое последующее расширение. Следовательно, в новой системе нам необходимо предусмотреть ряд свойств, которые позволят нам не повторить ошибки. Нам нужно при плановой и пиковой нагрузке горизонтально масштабировать ресурсы, иметь возможность наращивания функционала без серьезного вмешательства и гибкой интеграции под нужды внешних агентов.
Поэтому при выборе способа построения программной структуры остановимся на микросервисной архитектуре. Пусть к ней можно предъявить много замечаний и сильно раскритиковать саму ее суть. Но в нашем случае именно такой концепт хорошо соотносится с описанной нами предметной областью. Каждый домен - это либо отдельный микросервис, либо набор родственных сервисов, разделяющий между собой одну или несколько зависимостей, описывающих структуру сущностей в домене.
Кроме того, взаимная логическая и программная независимость микросервисов друг от друга позволят нам максимально распараллелить процессы доработок системы. Становится проще решить задачу удовлетворения потребностей разных бизнес-заказчиков в рамках общего проекта развития системы - предоставить каждому из них фактически индивидуальную ее версию, при этом не затрачивая месяцы разработки, а просто группируя сервисы по новому.
Основой нашей программной архитектуры будет выступать брокер сообщений, осуществляющий гарантированную доставку сообщений в стандартизированном формате между разными сервисами. Каждый микросервис будет работать асинхронно - то есть получив внешний запрос, он сразу ответит идентификатором сообщения, по которому внешний агент может обратится в дальнейшем за уточнением статуса обработки отправленного сообщения. Далее, сервис опубликует сообщение в брокер и будет слушать очередь, в ожидании ответа. После получения которого, он широким вещанием оповестит всех участников о результате.
Для преобразования асинхронного внутреннего взаимодействия с внешним синхронным, в нашей системе будут использоваться сервисы-фасады. Внешний агент или интерфейс, при обращении к фасаду, будет ждать ответ, а фасад уже сам будет отслеживать получение асинхронного ответа от микросервисов по предоставляемому ими идентификатору и возвращать его в установленную сессию. Сами микросервисы при этом не будут ожидать ответа после отправки сообщения в брокер (не будут хранить никакого состояния)
С “нижней стороны” к брокеру сообщений присоединены так называемые инфраструктурные сервисы, которые себя будут реализовывать логику работы с внешними источниками данных или другими системами. При этом делать это, абсолютно абстрагируясь от конкретного процесса, в рамках которого поступило сообщение, то есть предоставлять универсальный API для всех потребителей. Для наглядности:
Таким образом, части слоя работы с внешними источниками становятся отделяемыми, что позволит сравнительно безболезненно заменять один на другой.
В итоге получим общую схему
Заключение
В процессе проектирования нашей системы мы пришли к пониманию, что в рамках заложенной архитектуры мы можем реализовывать не только задачи, напрямую связанные с хранением документов, но также и косвенные бизнес-процессы, которые затрагиваются процессом поступления документа на хранение. Например, процессы, связанные с юридически значимым документооборотом. В следующих статьях я расскажу о выборе технологий реализации этого проекта, организации процессов взаимодействия с командой и внешними заказчиками.
