За что не любят архитекторов предприятия

Иногда я буду делать небольшие критические обзоры текстов разных авторов. Сегодня мне попалась заметка 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, но это совсем другая история, которую я рассказываю на курсе «Мастерская проектирования ИТ-решений»

За что не любят архитекторов предприятия: 2 комментария

  1. I understand the importance of considering the interconnectedness of all elements. Using explicit constructs like verbs as nodes is an excellent approach for modelling.

    However, our models must reflect reality at some point, and I’ve found that starting with a strong point of reference, a meridian, if you will, is essential for creating understanding. This is particularly important when dealing with Services which are the shopfront or gateway to an intended purpose. It is easy to lose them in the noise of the component and container as APIs, for example. But if you are creating things like a Data Mesh, they become critical to the whole strategy. You will want to see them in isolation, as the saying in English suggests, “Seeing the Wood from the trees”.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *