На современных проектах объектно‑ориентированные подходы могут стать универсальным средством построения API, а файлы YAML — понятной всем нотацией при интеграции. В новой статье рассмотрены оригинальные объектно‑ориентированные подходы для проектирования архитектуры цифрового офиса сотрудника РСХБ.

Например, DDD может быть реализовано аналитиком через онтологическую разметку предметной области. При разработке приложения специалисты РСХБ‑Интеха опирались на методику экспрессной визуализации объектов предметного поля через анализ чата в мессенджере с помощью методов математической лингвистики, также применяли адаптированную матрицу Эйзенхауэра для определения важности элементов интерфейса, методику определения границ микросервиса и концептуальную схему построения микросервисного конвейера.

О важности разметки предметного поля при анализе

Как сделать мобильное приложение для сотрудников банка? Не для клиентов, а для сотрудников. Клиенты у всех банков более‑менее однородны, их интересует стандартный набор функция: оплата, кредиты, ипотека. А как быть с нуждами сотрудников? И что нужно в приложении сотрудникам именно нашего банка? Да и для чего вообще им нужно приложение?

Удаленщику, работающему в ИТ на проекте создания мобильного приложения надо выходить из дома в обед. Какая же прогулка без плеера в ушах? В плеере играет Егор Летов:

«Великие стволы обрастают ветвями,
Ветви не вечны — становятся суками.
Сучья рубят, мы летим как ракеты
В сияющий космос внутри»

Действительно, любой бизнес‑процесс, как ствол, постепенно обрастает побочными ветвями, которые со временем могут терять свою актуальность. И как разметить предметное поле? Важно осознавать, что бизнес‑процесс всегда вторичен, первичными же всегда являются субъект‑объекты, которые в нем участвуют. Также, важно понимать, что однажды выделенные субъекты‑объекты могут участвовать в нескольких бизнес‑процессах, и при появлении нового нужно лишь набрать необходимое количество уже имеющихся субъектов‑объектов. Ну, или выделить новые.

Есть много методик определения зрелости ИТ‑проектов. Одну из таких методик можно построить на основе подхода к роли аналитика на проекте. В зрелых ИТ‑проектах аналитики не являются техническими писателями, готовящими документацию в виде требований, но являются архитекторами решений, видящими эти самые требования в контексте интегральной бизнес‑цели.

«Я летаю снаружи всех измерений», — поет Егор Летов. Отличный слоган для роли аналитика на зрелом ИТ‑проекте, ведь одно решение может затрагивать и сторонние проекты. И одна фича оказывает влияние на процесс обеспечения другой фичи. В продуктовой команде должен быть кто‑то, кто смотрит на ситуацию снаружи. Как было бы хорошо, если бы аналитик давал разработчику формализованное описание класса языка программирования!
И как же нам, проектируя конкретные решения, оставаться в итоге «снаружи всех измерений»?

С нашей точки зрения, любой бизнес‑процесс является производной. Первообразной же всегда будет набор субъектов‑объектов, которые взаимодействуют друг с другом в рамках делового оборота банка. Логично предположить, что и определение границы микросервиса можно построить на определении состояний субъекта‑объекта.

Таким образом, построение любого ИТ‑решения начинается с определения фундаментальной архитектуры, или как говорят с HLA (high level architecture) — архитектуры высокого уровня. HLA надо строить на основе анализа, надо определить: с какими объектами или процессами мы будем иметь дело, что собираемся автоматизировать созданием приложения, с чем имеем дело, разметить предметное поле. И для разметки предметного поля мы можем пойти двумя путями:

1. подход функциональный

2. подход объектно‑ориентированный.

Все чаще говорят, что наиболее правильный подход — это DDD (Domain Driven Architecture), при котором мы берем выделенные рамках анализа бизнес‑объекты со всеми их состояниями и укладываем в домены. Хорошо бы сделать так, чтобы одному бизнес‑объекту соответствовал один класс языка программирования (в языке программирования JAVA будем сразу говорить о DTO — Data Transfer Object), одна таблица баз данных и один объект JSON. Хорошо бы все связи между объектами получить в форме графа. А прийти к DDD можно только через построение онтологии — универсальной концепции предметного поля.

В ходе работы и многолетнего опыта создания мобильных приложений мы пришли к выводу, что онтологию можно описать не каким‑то абстрактным OWL, а вполне конкретным YAML. В этом пункте наших рассуждений стоит отметить, что приложение для сотрудников банка не будет являться высоконагруженным и требующим сложных интеграций и композитных интегрирующих агентов.

Действительно, большинство интеграций в мобильных приложениях строятся в простом архитектурном стиле REST API. Если реализовывать микросервисы в парадигме «один объект — один микросервис», то любой бизнес‑процесс — это суперпозиция CRUD‑операций, реализованных через использование глаголов протокола HTTP, поэтому взглянув на файл YAML станет понятно и предметное поле, и суть процессов, которые в нем реализованы.

Чат в телеграмме как источник онтологии

Когда случилась пандемия, и ИТ‑компании начали уходить на удалёнку, то появились трудности в понимании и коммуникации. Если команда работала до пандемии «очно» и ранее хорошо уяснила задачи, цели и смысл используемого сленга, то проблем не возникало. Проблемы начинались при появлении новых людей в команде. Тяжело, находясь удаленно, понимать контекст ситуации. В этот момент огромную роль начали играть чаты в мессенджерах. Они стали средством коммуникации и синхронизации. Если раньше, онтология рождалась в курилках, то теперь её можно почерпнуть из чата в телеграмме. Как это сделать?

• Вот хорошо бы было, если бы появилось средство экспрессной визуализации предметной области. Чтобы был граф, связывающий все субъекты‑объекты предметного поля.

• Телеграмм как мессенджер удобен в работе тем, что всю информацию из чата можно довольно легко выгрузить в виде файла в формате JSON и подвергнуть анализу методами математической лингвистики. Если векторизовать все сущности и разложить их в алфавитном 33-мерном пространстве, то можно получить граф предметной области.

• Подобно тому, как в космосе галактики начинают сгущаться вокруг точки сингулярности, все субъекты‑объекты начинают собираться на графе взаимосвязи вокруг бизнес смысла. Бизнес‑смысл стал новой гравитацией. И если построить такой граф, то можно осознать масштабы и предположить будущую концепцию архитектуры. Давайте попытаемся получить наиболее актуальные темы частотным анализом из чата с заказчиком. Будем руководствоваться принципом, что чем чаще заказчик говорит или поднимает какую‑то тему, тем она важнее.

Нами были выделены такие сущности:

• Пользователь

• Личный кабинет пользователя

• Новости

• Заявки

• Справки

• Календарь

• Мотивация сотрудника

• Объявления сотрудника

• Идеи сотрудника

• Опросы

Если темы выделены, то можно определить семантические ядра и смотреть, какие высказывания в чате попадают через сравнение алфавитных векторов в семантические орбиты и тем самым пытаться выстроить граф предметной области.

Концептуальное построение бека

Концептуально к микросервисам мы будем относиться как к хранилищу данных, в котором удаленно (другим микросервисом или фронтом) могут вызываться процедуры, приводящие к изменению данных о выделенном объекте. В некую среду, обеспечивающую возможность регулярной доставки изменений и балансировки нагрузок, разворачиваются контейнеры с микросервисами.

Микросервисы строятся по следующему правилу: один выделенный в ходе анализа объект — единственный микросервис. У каждого микросервиса своя база данных. У него есть конечная точка, через которую можно получать, передавать, а также обновлять данные с помощью REST API. Иногда такую концепцию построения системы на обращении к данным через конечные точки глаголами HTTP называют Restfull. Комбинацию описанных Мартином Фаулером «remoute call» и «messaging» при использовании REST API называют JSONRPC и все чаще противопоставляют известному протоколу SOAP.

Подобная схема ложится в известную нам со времен SOA парадигму «система потребитель» — «система поставщик». Только в данном случае потребителями (source) и поставщиками (target) будут являться не монолитные системы, а микросервисы.

Вопрос об организации асинхронного взаимодействия при использовании REST API можно решить. Асинхронность может регулироваться величиной таймаута, после которого последует повторный вызов.

На этапе анализа, после выделения основных сущностей аналитики могут создать файл YAML, в котором будут указаны основные объекты, конечные точки и запросы. При использовании определенных библиотек языка программирования JAVA, файл YAML можно использовать для генерации кода.
Обмен сообщениями (messaging) осуществляется путем прикрепления к REST вызову Body в формате JSON.

По структуре и топологии DTO должно совпадать с JSON. Следовательно, нам необходимо собрать все возможные атрибуты объекта, применяемые во всех процессах и сделать универсальный JSON, подходящий под все операции. При использовании подобного подхода в формировании JSON необходимо обязательными сделать только идентифицирующие объект атрибуты, остальные же сделать строго необязательными.

Вопрос о валидации данных в данном случае может решаться за счет применения JSONSchema. Да и вообще JSONSchema — это очень удобная нотация для проектирования корпоративной модели данных, бизнес‑глоссариев и предоставления открытых API систем, с которыми необходимо интегрироваться.

Раньше, осуществляя интеграцию в парадигме SOA мы передавали XML. Если у нас была корпоративная модель данных, то мы делали XML на две части: в одной части мы передавали информацию о бизнес‑процессе, в другой части передавали мета‑информацию с техническими параметрами передаваемого сообщения.

Если использовать для Remote Call и messaging архитектруный стиль REST API, то проектировать структуры для мета‑информации смысла нет, потому что информацию о сообщении можно передавать в header (заголовках) запроса REST. Так в заголовках мы можем передавать тайминговые параметры, форматы, название систем‑потребителей и прочую техническую информацию.

Проектируем фронт и интерфейс

Объектно‑ориентированный подход позволяет применять принципиально новые методы для проектирования интерфейсов. Представим себе ситуацию, при которой для контроля какого‑то процесса вы вынуждены постоянно переключаться между экранами, поскольку различные метрики и процессы расположены на разных экранах.

Другая, часто возникающая проблема, это то, что наиболее часто интересующие метрики, как и информация, находятся в глубине интерфейса и требуют нескольких кликов по экрану.

Если мы используем объектно‑ориентированный подход, то можно для определения объектов использовать матрицу Эйзенхауэра. Разложив объекты на 4 группы, мы сможем предварительно оценить степень их важности друг перед другом. Если построить граф интерфейса, узлами которого будут объекты, а ребрами 1 клик, то можно оценить «глубину кликов», то есть понять, сколько раз пользователю необходимо будет кликнуть на экран мобильного устройства, прежде чем увидеть необходимую ему информацию.

Для формирования интерфейсов также эффективно использовать так называемые «намерения», то есть взаимосвязи между объектами в рамках отдельно взятого бизнес‑процесса. Необходимо учесть не весь объект целиком, а только те его атрибуты, которые интересны заказчику или пользователю.

Важно осознавать, что в данный момент дизайнер — полноценный член продуктовой команды. Да и мало того, что полноценный! Часто бывает, что и наиболее высокооплачиваемый. Как ему передавать задание на разработку — вопрос на данный момент не до конца определённый. Как правило, дизайнеры в ИТ — это выпускники «худграфов», а не математики‑технари. И подходы, характерные для технарей, не годятся для дизайнеров. Наш метод передавать дизайнерам намерение, может стать универсальной концепцией, основанной на объектно‑ориентированном подходе. К тому же, такое намерение становится ясно на верхнем уровне при просмотре схемы REST вызова в формате YAML или JSON. При сочетании намерения с матрицей Эйзенхауэра, дизайнеру становится ясно, какие элементы надо показать в первую очередь, а какие во вторую, и какие при этом стоит выбрать виджеты.

Соответственно, при отображении на экране мобильного устройства информации о каком‑то объекте, вызов идет в конечную точку (end‑point) соответствующего микросервиса (он для последующих вызовов становится потребителем) и далее в соответствии с намерением в другие микросервисы (они становятся поставщиками). Фронт же не видит и никак не влияет на все вложенные вызовы.

Выводы

Конечно, это не все преимущества объектно‑ориентированного подхода. Можно еще рассказать о построении ролевой модели, разграничении доступа, обеспечении безопасности и многих других очевидных плюсах. Выводов и размышлений хватит еще не на одну статью. Хочется сказать о важном: любое ИТ‑решение обречено на забвение, если не предусмотреть универсальную возможность его интеграции с другими ИТ‑решениями. Такой универсальной возможностью может стать открытое и интуитивно понятное всем API, созданное на основе известных бизнес‑объектов.

Спасибо за внимание! Ещё больше полезной информации, а также технический стек по бэку можно найти на сайте РСХБ в цифре, а проверить знания языков программирования и технический бэкграунд здесь.