За что не любят архитекторов предприятия
(Из ленты Архитектура информационных систем)
Иногда я буду делать небольшие критические обзоры текстов разных авторов. Сегодня мне попалась заметка David R Oliver C4+1 — The Services Layer. В статье много есть к чему придраться, но я постараюсь только по существу.
Поначалу предложенное Дэвидом расширение С4 модели до С4+1* просто вызывает некоторое недоумение. Зачем портить и так хорошую вещь какими-то расширениями? Но все встаёт на свои места, когда вы дочитаете этот текст до раздела Mapping C4 to TOGAF Metamodel. Так и хочется воскликнуть: опять пришли эти корпоративные архитекторы и всё испортили!
Напомню, концепция бизнес-сервиса в метамодели TOGAF является основным инструментом связывания элементов из домена бизнес-архитектуры с элементами остальных доменов: приложений, данных и технологий. Можно назвать её ассоциирующим классом, объединяющие прочие элементы.
Естественно, использование таких подобных опосредованных отношений не упрощает модель и мешает нормальным людям понять конструкции корпоративных архитекторов. (Вот за это нас порой и не любят!)
Похожая вещь случилась с UML в 90-ые годы прошлого века. Организацию информационных системы, никто не собирался считать отдельной предметной областью, т.е. доменом. Вместо того, чтоб предложить конкретный адаптированный язык моделирования, включающий файлы, процессы, потоки ввода-вывода и всё прочие части информационных систем того времени, компания Rational для архитектуры информационных систем предложила воспользоваться крайне высокоуровневой концепцией узлов и развертываемых на них компонент. Практически все предметы реального (да и делового) мира могут быть вписаны в такую модель. Машина – узел, пассажир – компонент, сидение – интерфейс. Компонент человек развертывается на позиции начальника отдела – узел. Такая свобода принесла не много однозначности при разработке моделей информационных систем. Так, например, в одних ситуациях сервис(процесс) СУБД можно считать компонентом, развертываемом на узле – операционная система, а в других считать его узлом, на котором развертывается конкретная схема БД. В общем, без дополнительной стереотипизации никак не обойтись. А вот С4 возвращает конкретику восприятия подобных моделей. Контейнер (СУБД, web- или application server) в ней — это всегда среда исполнения компонента. Всё понятно, никакой двусмысленности. Так что не прав автор в самом начале своей статьи:
A recurring challenge in C4 is the ambiguity often encountered in differentiating between Containers and Components
Могут ли быть полезны в C4 дополнительные способы группировки элементов? Наверняка. Собственно подобные примеры и приведены в разделе статьи, называемой Use Cases. Но такая группировка будет между уровнем системы и контейнера. Например, единица развертывания pod в k8s может включать в себя несколько контейнеров: приложение и какой-нибудь sidecar. Микросервис – объект, занимающий промежуточное место между контейнером и системой. Но подобная конструкция не требует добавления в метамодель дополнительной сущности. Вот здесь уж точно будет достаточно меток или стереотипов.
Так зачем же портить хорошую вещь дополнительными уровнями?
—
* «Пасхалка» к Philippe Kruchten Architectural Blueprints — The “4+1” View Model of Software Architecture очевидна. Но в оригинальной работе выделение пятого представление – Use Case View в формат «+1» было сильно по существу. Я бы даже вспомнил потерянную (lost) диаграмму UML, но это совсем другая история, которую я рассказываю на курсе «Мастерская проектирования ИТ-решений»