Подходы к принятию архитектурного решения:
3. Формальный подход

В этом случае фиксируем архитектурно значимые требования (драйвера) и используем определённый алгоритм для выбора решения.

Примеры:
1. ABAS (Attribute-Based Architectural Styles от SEI) - алгоритм выбора архитектурного стиля на базе атрибутов качества.
2. ADD (Attribute-Driven Design от SEI) - алгоритм выбора решения на базе атрибутов качества.
3. Деревья принятия решений различных авторов (Нил Форд, Мартин Фаулер и др.).
4. LAAM (Lean Architecture Analysis Method) и аналогичные - алгоритмы с применением матрицы принятия решений
5. Матрица противоречий ТРИЗ (переработанная под архитектуру).

Преимущества:
1. Быстрое решение.
2. Может быть применено архитектором не имеющим опыта по теме.

Применимость:
Хорошо работает при формировании короткого списка решений. Легко определить неподходящие варианты.

Проблемы:
Выбор оптимального варианта затруднен, так как формальный подход не учитывает всего многообразия вводных и не базируется на контексте принятия решения.

Особенности:
Результат применения формального подхода сильно зависит от применяющего подход архитектора. За архитектором выбор вводных и трактовка результата.

Работая над решением задачи, всегда полезно знать ответ заранее (Закон точности)

#ПринятиеРешения

Подходы к принятию архитектурного решения:
4. Метод перебора

Этот подход известен также под именем морфологический метод.

Шаги:
1. Формируем список всех возможных/известных вариантов решения (фантограммы).
2. Определяем критерии пригодности (фитнес-функции).
3. Верифицируем варианты и отбрасываем нежизнеспособные.

Преимущества:
1. Позволяет выйти на оптимальное решение.
2. Продолжительная, но простая (механическая) работа, не требующая высокой квалификации.

Применимость:
Работает при возможности быстрой верификации. Например при верификации моделированием, без вывода решения в код.

Проблемы:
1. Требуется наличие списка вариантов (каталоги архитектурных концептов)
2. Затратен, так как требуется верификация большого количества вариантов.
(Обезьяна за печатной машинкой)

Упрощенный вариант:
Верифицируем варианты решения последовательно до нахождения первого подходящего.
В этом случае затраты существенно ниже, но и оптимальность результата не гарантирована.

Особенности:
Если верифицируется готовое решение (воплощенное в код), то должна быть возможность переписать решение за одну итерацию (эволюционная архитектура).

#ПринятиеРешения

О терминологии в IT

Забавно вновь и вновь наблюдать споры вокруг слов. Что такое архитектор, что такое микросервисы, что такое ddd и так далее до бесконца.

Как будто много веков назад для разрешения подобных споров люди не придумали научную методологию и механизм определений.

Можно что угодно понимать под словом "архитектор" и отстаивать свое мнение с пеной у рта.

А можно прочитать, что в этот термин вкладывал автор концепции, и как эта концепция развивалась во времени.

Отсутствие явных и точных определений известных каждому серьезно сдерживает развитие сферы IT.

Потребность в архитекторе

Перефразируя Черчилля:

Необходимость в архитекторе обусловлена тем, что предпочитает менеджер: платить или расплачиваться.

ADR и "перспективы"

ADR как способ фиксации архитектурных решений на пике популярности.

Однако, есть запросы не покрываемые данным подходом.
Например, требуется определить какие решения предприняты для обеспечения отказоустойчивости.

"Старые" методологии (например Розански и Вудс) предлагали "перспективы" (см. https://www.amazon.com/Software-Systems-Architecture-Stakeholders-Perspectives/dp/0321112296).
Перспектива это раздел описания посвященный одному качеству (например производительности).

Я хотел бы объединить эти два подхода.
Для этого нужно иметь возможность группировать архитектурные решения (ADR) по качествам (а возможно и по бизнес функциям).

Задача выглядит простой пока не попытаешься реализовать это практически:
1. Гит не дает тегать общим тегом несколько коммитов
2. Конфлюенс плохо демонстрирует динамику и плохо связан с этапами работы в гите.
3. Хочется использовать obsidian с тегами обратными ссылками и привязкой к git. Но тут проблема - инструмент новый и уговаривать на переезд придется долго )

Коллеги, а у вас есть опыт фасетной группировки арх. решений?

#Документация

Закономерности развития ИТ систем

В очередной раз убеждаюсь в правоте герметики - "То, что находится внизу, соответствует тому, что пребывает вверху; и то, что пребывает вверху, соответствует тому, что находится внизу".

Сервисные архитектуры почти идеально повторяют решения выработанные адептами ООП.

Единая цель "снижение когнитивной нагрузки на разработчика" приводит к одним и тем же структурам.

Приведу несколько примеров:

1. Независимая разработка потребовала введение объектов на уровне монолита и сервисов в распределенной системе.
2. Устраняя связанность по данным получили инкапсуляцию в ООП и автономность с собственными БД в сервисах.
3. Усиливая автономность ввели понятие строгих контрактов в ООП и аналогично на сервисах (API и т. п.)
4. Модули закрыли фасадами. Сервисы закрыли шлюзами.
5. Разделяя бизнес логику и сценарии использования в ООП ввели слой приложения и сервисы приложения. В сервисных архитектурах появились оркестраторы.
6. Минимизация связанностей привела к понятию "домен" в который объединяется множество объектов. Тот же самый механизм использован при объединении сервисов (см. например DOMA от Uber)

и так далее и тому подобное.

ИМХО, глядя на эти соответствия можно не только находить общие закономерности в развитии архитектурных стилей, но и предсказывать новые решения.

Структура архитектурной документации

В любом арх. процессе присутствуют следующие группы арх. артифактов:
1. Сырье - необработанное нечто на входе.
2. Требования, гипотезы или как назовете - нечто после анализа и структурирования.
3. Решения с обоснованиями
4. Модель (точнее их множество)
5. Представления, rfc, презентации - выжимки для коммуникаций.

- документирование всего этого хозяйства целиком/частями опция и выбор зависит от массы факторов

Сырье кидаю в обсидиан в папку raw и мечу тегами под поиск.

Требования беру у аналитиков и докидываю свои драйвера - текст с трассировкой на jira

Решения - madr

Модель веду в конфлюенсе (в текущем проекте), но предпочел бы archi

Представления размазаны по конфлюенсу (rfc) и разным документам (в основном powerpoint)

А хочется единого пространства и удобной трассировки (

#Документирование

http://microservices.io/i/SuccessTriangleWithBooks.png

Красивая картинка у К. Ричардсона.

"Ignoring those two elements is a common anti-pattern of microservice adoption."

Нефункциональные требования и ограничения (Constraints)

Для того чтобы принять оптимальное архитектурное решение необходимо обработать большой массив входящих данных (т.н. архитектурных драйверов или мотивов).

Часть этих данных структурирована, часть нет (т.н. контекст проектирования).

В одном из арх. каналов возник спор по поводу структурированных данных.
Было предложено всех их обобщить термином "требования".

В этом вопросе я придерживаюсь классического подхода - разделяю требования и ограничения.

Зачем? Казалось бы, и то и другое приходит от стейкхолдеров и формирует архитектуру. В чём разница?

Мои резоны:
1. Среди всех стейкхолдеров я выделяю потребителя. Того для кого готовится продукт.
Требования прочих заинтересованных лиц ограничивают развитие продукта, а зачастую и ухудшают его потребительские качества.

Пользователю нужна функциональность, производительность, надежность и безопасность . Это требования.

Служба эксплуатации ограничивает список технологий. Смежники диктуют интерфейсы и протоколы. Бизнес ограничивает время/деньги. Команда предоставляет ограниченный набор скиллов. Это ограничения.

2. Мне нравится подход, при котором я сперва проектирую идеальную архитектуру, которая бы на все сто удовлетворила пользователя, а потом начинаю "портить" ее имеющимися ограничениями.

3. В моем понимании требования непреложны (атрибутивны), а ограничения оспариваемы (акцидентны) и ради хорошего продукта я могу преодолевать ограничения в архитектуре надсистемы.

#АрхитектурныеДрайвера

База знаний в обсидиане

Затемплайтил свою архитектурную базу знаний со структурой, темой и настроенными плагинами.

Теперь для включения в новый проект достаточно распаковать и запустить.

Положу здесь. Возможно, еще кому-нибудь пригодится.

#Документирование

Анти-паттерн "42"

Всегда восхищался способностью арх. комов и некоторых продвинутых архитекторов оценить архитектуру по её описанию.

Лично мне трудно оценить правильность ответа на «главный вопрос Жизни, Вселенной и Всего Остального», без понимания вопроса.

При этом под "пониманием вопроса" я подразумеваю не только требования.
В случае архитектуры это еще и глубокое погружение в контекст.

#Антипаттерны #Сарказм

Транзакционность

Опять попал на обсуждение вопроса о том, что есть САГА: ACID, ACD или даже CID.
Полная путаница в терминологии приводит к бесконечным холиварам.

Хотел бы здесь зафиксировать своё понимание транзакционности.

1. Транзакция - минимальная логически осмысленная операция.
2. Выполнение транзакции не должно ломать целостность или когерентность данных.
Это свойство называется согласованностью (consistency) в широком смысле слова.
Что бы не путаться я называю его транзакционностью )
То есть транзакция должна быть транзакционной ))
3. Угрозы целостности и когерентности:
- одна из операций транзакции не может быть завершена (по бизнесу)
Решается атомарностью (Atomicity), которую Мартин Клеппман называет abortability.
- операции на разных ресурсах могут выполняться в произвольном порядке
Решается согласованностью в узком (ACID) смысле
- операции от разных клиентов могут мешать друг другу
Решается изолированностью (Isolation)
- операции могут завершится неудачей в следствии сбоя, в частности по таймауту
Решается устойчивостью (Durability)
4. Соответственно, хорошая транзакция должна поддерживать ACID.
Но при этом всегда можно пойти на компромиссы.

План по поддержке транзакционности примерно такой:
1. Определить список основных операций.
2. Определить требования по производительности, надежности и целостности/когерентности
3. Определить требуемый уровень согласованности (по NFR).
4. Определить механизм поддержки согласованности. (централизованный/децентрализованный, синхронный/асинхронный).
5. Определить механизм поддержки атомарности (кто и как делает откаты).
6. Определить требуемый уровень изолированности (по списку операций).
7. Определить механизм устойчивости (например SAGA vs TCC)
8. Реализовать )

#Транзакционность

Сага

Продолжая предыдущий пост, хотелось бы ответить на вопрос, что есть Сага.

Ad ovo:
1. В распределенной среде долгоживущие транзакции могут обеспечить транзакционность (ACID) на блокировках. Работает это очень ненадёжно и медленно.
В 1986 году Hector Garcaa-Molrna, Kenneth Salem предложили разбить транзакцию на несколько мелких локальных и назвали это сагой.
С их точки зрения сага была не атомарна, то есть CID.
Так как атомарностью они назвали принцип "Всё или ничего" (БД-шное понимание атомарности).
2. Мартин Клеппман переопределил атомарность как abortability. То есть как возможность прервать и откатить транзакцию в случае отката одной из операций. В этом понимании Сага вполне атомарна (ACID).
3. Однако, в процессе проведения Саги часть транзакций может быть закомичена до общей фиксации. То есть конкуренты увидят результаты незавершенной транзакции. Крис Ричардсон считает, что это явное нарушение изоляции. То есть Сага - ACD.
4. Криса ругают и доказывают, что изоляцию для Саги построить легко. Например, на блокировках. С моей т.з. сага с блокировками противоречит идее создания саги и уже и не сага вовсе. И Крис таки прав.

#Сага #Транзакционность

BPM-движки

Глядя на различные системы, использующие bpm-движки (camunda, zeebe и ежи с ними), осознаю некоторое неустранимое противоречие.
По пунктам:
1. BPMN - нотация моделирования.
2. BPM - модель процесса. То есть некоторая абстракция, упрощение.
3. Движок предполагает реализацию.

Как авторами концепции предполагалось заполнить пробел между абстракцией и реализацией?

Они реально думали, что модель нарисованная, например аналитиком, сразу же заработает как реализованный алгоритм?

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

Архитектурное решение

Мне не нравится когда говорят, что архитектор принимает решение.

Принимать решение удел менеджера.

Архитектор обдумывает и прорабатывает решение.

Процесс архитектора несколько более затратный.

Это не сложный выбор и не волевое действие.

Это полное погружение в задачу, до формирования необходимых нейронных цепей, до ясности понимания.

Нужна архитектура за день? Да пожалуйста. Только то будет не совсем "архитектура".

Аутсорсинг

Плюс - не скучно.
Минус (жирный) - каждый раз в новом домене и на новой платформе начинаешь с нуля.

Только что был экспертом и опять джун)

Фрагментарность ИТ-знаний

Большая проблема ИТ инженерии - фрагментарность знаний.
При этом каждый фрагмент написан автором на своём, зачастую уникальном, языке.

Причины понятны:
1. Знания формируются бессистемно, рецептурно различными, не связанными с друг другом авторами.
2. Цель - найти приемлемое рабочее решение, и не более.

Приведу пример.

1. Сущность (entity) у Эванса это идентифицируемый объект.
В DDD идентифицируемость указывается как самое важное свойство сущности. При этом Эванс предостерегает от превращения в сущности всего и вся, намекая на некоторые проблемы связанные с поиском эквивалентности.
2. Проблемы сущностей описаны у М. Фаулера в "Аналитических паттернах". Правда термин "сущность" здесь не упоминается. Паттерн называется "обращение к объектам" ("Referring to Objects"). Основные проблемы по Фаулеру порождаются несколькими источниками возникновения сущности. Эти проблемы: множественная идентификация, слияние и поиск эквивалента. Фаулер даёт несколько паттернов решения проблем не углубляясь в их реализацию.
3. Столкнувшись на практике с проблемами сущности вы скорее всего будете реализовывать сущность как золотую запись. Еще один термин, в этот раз из мира управления данными.
Вам потребуется MDM система. Возникнут вопросы связанные с природой сущности (НСИ, товар, продукт, контакт и т. п.), так как для каждого вида существует своя оптимальная MDM (RDM, PDM, CDI и др.)

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

Синтезируем это всё в голове архитектора.

И к сожалению, никто не берётся за систематизацию этого бардака (

Утилита для расчета SLA по доступности

Понадобилось быстро перекинуть девятки в часы.
Обычно пользуюсь для этого таблицами.
Сегодня набрел на удобную утилиту, ссылку на которую оставлю здесь.
https://shootnick.ru/uptime/

Связывание по структуре данных (stamp coupling)

Казалось, что времена огромных отраслевых XML и таблиц в далёком прошлом.
Ан нет.(

Очередной заказчик предлагает собрать все возможные документы и обобщить их в единую структуру.

Нехилое развлечение для аналитиков.

Вопрос "что будет при появлении новых документов или при модификации существующих" - не возникает.

То, что сервисы шарящие базу, будут связаны как сиамские близнецы - проблема технарей, бизнес не волнует.

Архитектора убежали от SOAP и с ужасом косятся на всякие gRPC. Так получим это все в реляционку.

Есть решение снимающее эти проблемы?

Есть и даже два:
1. Свободный контракт от потребителя
(идеален, но требует зрелости команды)
2. Свободная форма (а ля k-v) + мета
(снимает связанность, но усложняет систему)

Продавливаем второй вариант

Архитектор-пропагандист

Хочу представить очень распространенный анти-паттерн "Архитектор-пропагандист".

Проблема:
"Специалист" вместо поиска решения активно продвигает "правильный" вариант, забыв основную мантру архитектора "It depends".

Симптомы:
Фразы типа:
- Это best practices, так все делают
- Это паттерн взятый у [имярек] и он не может быть неправильным
- Мы делали так на предыдущем проекте, и это великолепно работает

Решение:
Любое правильное "решение" должно быть взвешено в конкретном контексте и подвергнуто сравнению с другими решениями.

Следствие:
Приведенное выше решение тоже не всегда верно)

#Антипаттерны

Логический и физический уровни системы

При архитектурном анализе системы рекомендую подход, разбивающий модель на логический и физический уровни.
Очень многое становится понятным.
Хороший пример области проблемы и решения в DDD.
Другой пример - распределённые транзакции (см. рисунок)

Бизнес процесс состоит из атомарных действий, которые отображаются на физические транзакции и (сюрприз!) не один в один.

Варианты:
Действие1. Идеальный расклад однозначного соответствия. Атомарность действия и атомарность реализации.
Действие 2. Грустный случай разбиения атомарного действия на две не атомарные транзакции. Этого стоило бы избегать, но не всегда возможно.
Можно попытаться связать физические транзакции блокировками (распределённая транзакция) - но получится нестабильно и медленно.
Делаем сагу. На логическом уровне атомарность. На физическом отменяемость (abortability у Martin Kleppmann).
Есть масса способов не дать клиенту увидеть проблемы реализации.
И пусть специалисты спорят атомарна ли сага))
3. Действия 3,4. Чрезмерное усложнение. Так лучше не надо.
Два неатомарных действия лучше догнать по итогу (eventually), чем мучиться с откатом и возможным неуспешным откатом.

#Сага #Saga