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

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

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

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

Имею опыт работы порядка 7 лет в банках уровня ТОП-5  и пришел к выводу, о том что до сих пор в разных командах нет единого понимания о том, какую же роль играют аналитики в командах и никто, включая самих аналитиков вам не скажет, какие обязанности должны ими выполняться. Ну кроме, пожалуй, единого мнения о том, что аналитик должен “писать документацию”. Хочется также отметить тот факт, что, само наличие аналитика в команде, которая работает по Agile, когда разработки по ТЗ в строгом смысле этого слова уже нет, уже само по себе проблема. И если банк у вас современный и вы работаете не по “водопаду”, а по какой-то более гибкой методологии, вам придется решать три проблемы анализа на банковских ИТ-проектах:

Вместо введения

Для кого я решил написать? Данная статья, написана для моих коллег аналитиков или для тех, кто желал бы им стать. Если вы теперь захотели стать аналитиком, то подумайте хорошенько. 

Микросервисы. С хайпом вокруг них, лучше быть разработчиком, архитектором, тестировщиком, проджект-менеджером, дизайнером. Хорошо быть кем угодно в микросервсиах, но только не аналитиком. Аналитик ведь всегда во всем виноват. Ни разу не слышал, чтобы в “факапе” и срыве сроков обвинили архитектора, ну или там разработку. Нет, господа, вина всегда лежала и будет лежать на плохой документации и нечетко поставленных задачах. Вот вся команда собралась и тычет в тебя пальцами. Дескать, это все он! Опытный архитектор спроектировал, хороший разработчик сделал, внимательный тестировщик протестировал, мотивированный проджект-менеджер обеспечил… а невнимательный аналитик все завалил. А меж тем, материалов по аналитике и как её вести на русском языке очень мало. И как “анализировать” эти самые микросервисы не совсем понятно. Более того, никто вам не скажет, чем “системный аналитик” теперь отличается от “солюшн архитектора”. Вот во всем этом я и захотел разобраться и поделиться. Поэтому, если вы не аналитик - не читайте. Вам не будет интересно. Ведь, нет в вас экзистенциального кризиса и вопросов “Кто я? и зачем я им нужен на проекте”.

В марте разработчикам в средах программирование пришло сообщение "New JDK version is available", что означало, что вышел очередной релиз Java 16 с открытым исходным кодом Java SE (Standard Edition) 16 и Java Development Kit 16 (JDK 16). Подготовка к выпуску окончена и набор новых функций (JEP), который был утвержден, теперь реализован в  JDK и опубликован в открытом доступе. Известно, что для 16-го релиза новых JEP уже не будет. А следующий, 17-й релиз выйдет в сентябре.  Ах да, что же такое JEP для новых релизов Java? Для новичка это всегда не очень понятно.

Есть ветхозаветная легенда о том, как люди в древнем городе Вавилон начали строить башню, но Всевышний перемешал им языки, и башня достроена не была. Еще бы, ведь башню строили сотни маленьких групп, которые в совокупности не понимали друг друга. А не понимая друг друга, невозможно взаимодействовать. Действительно, просто безумие – называть одну и туже вещь, подразумевая её одинаково, разными словами. И удивительного тут ничего нет.

Ветхозаветную легенду можно с легкостью перенести на современные крупные компании, внедряющие современные ИТ-решения. В пример таких компаний, вне всякого сомнения, можно отнести современные российкие банки, которые имеют десятки, а то и сотни бизнес-подразделений, в которых складывается своя субкультура общения, построенная на своих правилах и уникальном стиле делового оборота. Естественно, при формировании ИТ-инфрастурктуры учитывается устоявшийся в коллективе стиль именования бизнес-сущностей. За последние десять лет появилось множество работ на эту тему, например эта [1]. Те, кто сталкивался с аналитикой информационных систем в банках знают, что такое сделать так называемый «маппинг» данных, особенно, если конечные системы делали разные команды аналитиков, разработчиков и заказчиков или вендоров. Как правило, на 60% составление маппинга является уяснением сути и семантики передаваемых данных.