Как известно, описание архитектуры состоит из множества представлений, для соответствующих точек зрения, интересов и заинтересованных сторон.
В этой статье я расскажу о способе создания представления (диаграммы) модели предметной области (МПО), дополненное связями с точками интеграции, на базе которых построена функциональность системы: хранимыми процедурами, функциями и веб-сервисами. Таким образом, данное представление хорошо подойдёт проектам с большим количество точек интеграций и поможет разработчикам и аналитикам быстрее ориентироваться в проекте, порой даже не заходя в код.
Разработка такого представления велась для оптимизации разработки интернет банка. Характерной особенностью подобных систем, является то, что они являются прослойкой над множеством внутренних банковских систем, предоставляющих множество точек интеграции для интернет банка. Поэтому данное представление может быть востребовано в интернет банках и других фронт системах в высокотехнологичных компаниях, использующих множество внутренних интегрированных систем.
Возможности, которые даёт такое представление:
Вопросы, на которые отвечает такое представление:
Представление строится на основе диаграммы классов. Для отображения сущности МПО используется класс. Сама сущность МПО представляет из себя абстракцию, которой может не существовать в реализации в описанном виде.
Аттрибуты сущности МПО содержат перечень основных полей, при этом они могут содержать не все используемые в коде поля, так как их может быть достаточно много и в этом нет смысла.
Название аттрибута задаётся в наиболее удобной для понимания форме. В случае с атрибутами чаще всего было проще использовать то название, которое указано в коде.
Методы бизнес-модели содержат все возможные действия, над данной моделью. Это могут быть CRUD и какие либо ещё возможные методы. Выделение метода зачастую ориентируется на точку интеграции, которая используется в данном методе. Есть смысл так же выносить производные методы, для понимания предметной области.
Название метода в бизнес-модели указывается в свободной форме, таким образом, чтобы по названию можно было понять его суть. Зачастую проще использовать русскоязычные имена. Например, метод получения списка банковских карт, будет иметь названия ПолучитьСписокКартПоКлиенту.
Точки интеграции — это могут быть хранимые процедуры, функции или веб-сервисы. Описываются по формату %схема/веб-сервис%: хп/хф/метод веб сервиса. Стрелкой соединяются с соответствующим методом.
Рисунок 1. МПО на примере одной сущности
Пример того, как описывается одна сущность МПО — изображён на Рисунке 1.
Итоговое представление МПО может выглядеть примерно как на рисунке. В примере я привёл значительно упрощённую модель. В реальной модели было в 10-15 раз больше сущностей с значительно большим количеством методов и точек интеграции. Однако даже с большими размерами МПО было достаточно просто ориентироваться. Свою роль сыграли возможностям Enterprise Architect и Visual Paradigm, однако в первую очередь помог логический поиск Функциональность->Сущность->Метод->Точка интеграции
Рисунок 2. Пример полного представления МПО.
На рисунке 2 изображён пример полного представления МПО. По этому рисунку уже можно сложить мнение о том, какая функциональность реализована в приложении.
Для наглядности я приложил диаграмму компонентов (Рисунок 3), распределённых по приложениям инфраструктуры проекта:
Эта диаграмма в статье только для того, чтобы дать представление о количестве слоёв в стэке вызова, которое может быть между элементами управления UI и интеграционной точкой, что влияет на анализ стэка.
Рисунок 3. Диаграмма компонентов.
Задача 1:
Допустим, что у нас стоит задача модифицировать функциональность открытия счёта и мы не знакомы с кодом проекта. В такой задаче может прийтись исследовать стэк вызова, а учитывая, что в каждом приложении существует свой набор компонентов, стэк вызова при клике на кнопку «Открыть счёт» может состоять из 8 уровней:
1 — ReactUI
2 — RestApiController
3 — AccountCachedController
4 — AccountServiceWrapper
5 — MainOnlineBackendServiceImplementation
6 — AccountServiceWrapper
7 — OnlineBankLogicServiceImplementation
8 — sheme1: sp_createAccount
Анализ сверху-вниз при помощи отладчика в такой ситуации может занять значительное время, так как на каждом слое, метод может содержать множество строк и ещё вложенные методы, которые будут либо возвращать обратно либо вести к другим точкам интеграции. Поэтому чтобы найти точку интеграции (а именно она выполняет действие), нужно будет прошарить отладчиком почти все строки стэка вызова.
В случае, если мы используем диаграмму МПО, то по соответствующему действию можно получить название хранимой функции, а через неё, с помощью глобального поиска по проекту, найти нужный участок кода и поставить на ней точку останова. Дальше остаётся только вызвать эту точку и идти по стэку вызова снизу-вверх, что значительно проще.
Задача 2:
Допустим, что у нас стала возникать ошибка при выполнении какого-либо действия. Для проектов с множеством интеграций частой причиной ошибок является ошибки внешних систем, например было выполнено обновление хранимой процедуры, отключение/недоступность веб-сервиса. На уровне пользователя такие ошибки совсем не очевидны и возникает ощущение, что проблема конкретно в системе, с которой работает пользователь. Чтобы локализовать ошибку чаще всего необходимо проанализировать стэк вызова.
В случае, если мы используем диаграмму МПО, то по действию, с которым происходит ошибка мы находим точку интеграции, ставим на неё точку останова и делаем вызов.
Если точку не поймали, то проблема лежит до вызова.
Если точку поймали, делаем вызов и смотрим прошёл ли вызов без ошибок. Очень часто на этом этапе находятся все ответы.
Если точку поймали и действие выполнилось, тогда идём по стэку снизу-вверх, пока не найдём ошибку.
Это две типовые распространённые задачи, при которых требуется находить точки интеграции.
Задача 3:
Другое множество, где диаграмма была полезна — это различные вопросы:
Задача 4:
Вы исследуете систему и вам необходимо накапливать информацию о всех понятиях и функционале системы. Диаграмма помогает это выполнять в достаточно лаконичном виде. В дальнейшем такая декомпозиция/композиция позволяет спроектировать архитектурные слои.
В этой статье я расскажу о способе создания представления (диаграммы) модели предметной области (МПО), дополненное связями с точками интеграции, на базе которых построена функциональность системы: хранимыми процедурами, функциями и веб-сервисами. Таким образом, данное представление хорошо подойдёт проектам с большим количество точек интеграций и поможет разработчикам и аналитикам быстрее ориентироваться в проекте, порой даже не заходя в код.
Разработка такого представления велась для оптимизации разработки интернет банка. Характерной особенностью подобных систем, является то, что они являются прослойкой над множеством внутренних банковских систем, предоставляющих множество точек интеграции для интернет банка. Поэтому данное представление может быть востребовано в интернет банках и других фронт системах в высокотехнологичных компаниях, использующих множество внутренних интегрированных систем.
Возможности, которые даёт такое представление:
- диаграмма МПО позволяет быстро получить понимание о функциональности, которая существует в системе, какие сущности присутствуют в системе и какие операции с ними можно выполнять;
- связь сущностей МПО с точками интеграции — ускоряет поиск нужного участка кода при модификации функционала. Понимая какую операцию и по какому объекту надо модифицировать, можно быстро найти точку интеграции, а отталкиваясь от неё — проанализировать весь стек вызова;
- удобно накапливать информацию о предметной области в простом наглядном стиле;
Вопросы, на которые отвечает такое представление:
- какие сущности МПО существуют в системе?
- как сущности МПО друг с другом связаны?
- какие действия можно выполнять с сущностями МПО?
- с помощью каких точек интеграции выполняются те или иные действия?
Представление сущности МПО
Представление строится на основе диаграммы классов. Для отображения сущности МПО используется класс. Сама сущность МПО представляет из себя абстракцию, которой может не существовать в реализации в описанном виде.
Аттрибуты сущности МПО содержат перечень основных полей, при этом они могут содержать не все используемые в коде поля, так как их может быть достаточно много и в этом нет смысла.
Название аттрибута задаётся в наиболее удобной для понимания форме. В случае с атрибутами чаще всего было проще использовать то название, которое указано в коде.
Методы бизнес-модели содержат все возможные действия, над данной моделью. Это могут быть CRUD и какие либо ещё возможные методы. Выделение метода зачастую ориентируется на точку интеграции, которая используется в данном методе. Есть смысл так же выносить производные методы, для понимания предметной области.
Название метода в бизнес-модели указывается в свободной форме, таким образом, чтобы по названию можно было понять его суть. Зачастую проще использовать русскоязычные имена. Например, метод получения списка банковских карт, будет иметь названия ПолучитьСписокКартПоКлиенту.
Точки интеграции — это могут быть хранимые процедуры, функции или веб-сервисы. Описываются по формату %схема/веб-сервис%: хп/хф/метод веб сервиса. Стрелкой соединяются с соответствующим методом.
Рисунок 1. МПО на примере одной сущности
Пример того, как описывается одна сущность МПО — изображён на Рисунке 1.
Представление МПО
Итоговое представление МПО может выглядеть примерно как на рисунке. В примере я привёл значительно упрощённую модель. В реальной модели было в 10-15 раз больше сущностей с значительно большим количеством методов и точек интеграции. Однако даже с большими размерами МПО было достаточно просто ориентироваться. Свою роль сыграли возможностям Enterprise Architect и Visual Paradigm, однако в первую очередь помог логический поиск Функциональность->Сущность->Метод->Точка интеграции
Рисунок 2. Пример полного представления МПО.
На рисунке 2 изображён пример полного представления МПО. По этому рисунку уже можно сложить мнение о том, какая функциональность реализована в приложении.
Как представление МПО + точки интеграции может упростить разработку
Для наглядности я приложил диаграмму компонентов (Рисунок 3), распределённых по приложениям инфраструктуры проекта:
- UIWebSite
- MainOnlineBackendService
- PCIDSSOnlineBankLogicService
Эта диаграмма в статье только для того, чтобы дать представление о количестве слоёв в стэке вызова, которое может быть между элементами управления UI и интеграционной точкой, что влияет на анализ стэка.
Рисунок 3. Диаграмма компонентов.
Задача 1:
Допустим, что у нас стоит задача модифицировать функциональность открытия счёта и мы не знакомы с кодом проекта. В такой задаче может прийтись исследовать стэк вызова, а учитывая, что в каждом приложении существует свой набор компонентов, стэк вызова при клике на кнопку «Открыть счёт» может состоять из 8 уровней:
1 — ReactUI
2 — RestApiController
3 — AccountCachedController
4 — AccountServiceWrapper
5 — MainOnlineBackendServiceImplementation
6 — AccountServiceWrapper
7 — OnlineBankLogicServiceImplementation
8 — sheme1: sp_createAccount
Анализ сверху-вниз при помощи отладчика в такой ситуации может занять значительное время, так как на каждом слое, метод может содержать множество строк и ещё вложенные методы, которые будут либо возвращать обратно либо вести к другим точкам интеграции. Поэтому чтобы найти точку интеграции (а именно она выполняет действие), нужно будет прошарить отладчиком почти все строки стэка вызова.
В случае, если мы используем диаграмму МПО, то по соответствующему действию можно получить название хранимой функции, а через неё, с помощью глобального поиска по проекту, найти нужный участок кода и поставить на ней точку останова. Дальше остаётся только вызвать эту точку и идти по стэку вызова снизу-вверх, что значительно проще.
Задача 2:
Допустим, что у нас стала возникать ошибка при выполнении какого-либо действия. Для проектов с множеством интеграций частой причиной ошибок является ошибки внешних систем, например было выполнено обновление хранимой процедуры, отключение/недоступность веб-сервиса. На уровне пользователя такие ошибки совсем не очевидны и возникает ощущение, что проблема конкретно в системе, с которой работает пользователь. Чтобы локализовать ошибку чаще всего необходимо проанализировать стэк вызова.
В случае, если мы используем диаграмму МПО, то по действию, с которым происходит ошибка мы находим точку интеграции, ставим на неё точку останова и делаем вызов.
Если точку не поймали, то проблема лежит до вызова.
Если точку поймали, делаем вызов и смотрим прошёл ли вызов без ошибок. Очень часто на этом этапе находятся все ответы.
Если точку поймали и действие выполнилось, тогда идём по стэку снизу-вверх, пока не найдём ошибку.
Это две типовые распространённые задачи, при которых требуется находить точки интеграции.
Задача 3:
Другое множество, где диаграмма была полезна — это различные вопросы:
- какая внешняя система отвечает за ту или иную функциональность
- какая точка интеграции используется для выполнения того или иного действия
- где получить номер карты по её Id
- кто отвечает за функциональность со стороны другой системы
Задача 4:
Вы исследуете систему и вам необходимо накапливать информацию о всех понятиях и функционале системы. Диаграмма помогает это выполнять в достаточно лаконичном виде. В дальнейшем такая декомпозиция/композиция позволяет спроектировать архитектурные слои.