Компоненты программной системы

Поздно подумал, что надо было проиллюстрировать предыдущий пост.
Ну лучше поздно, чем никогда.)

Причины декомпозиции

«Вах, зачем ты предлагаешь мне декомпозицию? Как это снизит связанность? Связи останутся те же, только часть из них станет внешними. В итоге мы получим медленные, ненадежные взаимодействия» (из разговора с заказчиком).

1. Говоря о причинах декомпозиции, многие вспоминают связанность.
Связанность (англ. coupling, рунглиш. каплинг) — мера взаимосвязи элементов системы.
Мол, декомпозировать нужно для того, чтобы уменьшить связанность.
Отнюдь.
Так можно договориться до того, что повышать качество системы нужно ради хорошего коэффициента покрытия модульными тестами.

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

3. Возьмём, к примеру, первичную декомпозицию системы. В редких случаях все ее части строятся на одной онтологии. Зачастую система распадается на множество элементов (доменов, предметных областей), описываемых различными языками. Заставьте разработчиков думать сразу на нескольких языках (Ubiquitous Language) и повторите судьбу строителей вавилонской башни.
Одним из паттернов первичной декомпозиции у Криса Ричардсона является декомпозиция по предметке
(см. https://microservices.io/patterns/decomposition/decompose-by-subdomain.html).
И где здесь про связанность?

4. Если уж говорить про метрики, то лучшей метрикой декомпозиции является сцепленность.
Сцепленность (англ. cohesion) — мера «близости» элементов системы.
Упрощая, мы можем проранжировать все связи по «правильности» и провести декомпозицию так, чтобы «правильные» связи попадали в общий элемент, а «неправильные» связывали элементы между собой.
Минимизировать количество и степень неправильных связей (снизить связанность) — это задача распределения ответственностей и дизайна взаимодействий, а не декомпозиции.

5. Список «правильных» и «неправильных» связей можно найти в стандарте ISO/IEC/IEEE 24765.
Однако этот список изначально был ориентирован на низкоуровневый дизайн и поэтому не полон.
Например, в этом списке есть сцепленность по общим данным, но нет сцепленности по общему языку, которую мы активно используем.

6. Хотелось бы хотя бы тезисно накидать алгоритм декомпозиции, указав, какие сцепки используются на разных уровнях иерархии системы.

Причины декомпозиции

Ну и запоздалая иллюстрация )

Уменьшение связанности
(«Правильный ответ»)

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

Но есть наборы тактик, позволяющих ослабить связанность, и это сужает область поисков.

У SEI таких тактик четыре (см. рисунок).

Правда, если внимательно вчитаться, то остается только две. )

Ограничение зависимости — это уточнение тактики «Посредник», посредник же — частный случай инкапсуляции.
Плюс абстрагирование, которое не уменьшает количество связей, а ослабляет их.

Оба решения были названы в комментариях.
Оркестратор — пример посредника.
Событийка на Publisher-Subscriber — пример повышения уровня абстракции.

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

Чуть позже покажу это на примере.
Судя по голосованию — активно напросился. )

Event messages vs Command messages

1. Многие не видят принципиальной разницы между этими сообщениями.
Действительно ли сообщения-события связывают компоненты слабее, чем сообщения-команды?

2. Команды (Что сделать)
Проектировщики команд, а вслед за ними и проектируемый компонент «знают», кто и как будет обрабатывать команду. И явно декларируют предсказанное будущее в имени сообщения.

3. События (Что произошло)
Проектировщики событий лишены этого знания. События уходят на «другую сторону реки» и могут быть обработаны по-разному разными получателями, а могут и вообще потеряться.
Мы не можем явно описать их дальнейшую судьбу. Но мы все-таки должны дать им имя, полезное обработчикам. Даем имя по их прошлому, сообщая, как они родились.

4. Взаимозаменяемость
Можно ли использовать события вместо команд?
Да. Но мы теряем замечательную характеристику команды — ясность.
Можно ли использовать команды вместо событий?
Очевидно, нет. Не хватает знаний об их дальнейшей судьбе.

5. Подводя итог
У компонента, посылающего события, меньше знаний о связанных компонентах (эфферентная связанность).
Их связывает только общее знание структуры события. Но за это мы заплатили ясностью.(

Event messages vs Command messages
(Иллюстрация)

В этот раз картинку не придумал, проиллюстрирую примером)

1. Предположим на подтверждение заказа вы запускаете процедуру доставки в другом сервисе.
2. Проще всего послать команду от сервиса заказов к сервису доставки (доставь_заказ(id)).
3. После выкатки релиза вас просят на подтверждение заказа добавить расчет бонусов.
4. Пишем еще одну команду к сервису бонусов, т. е. модифицируем сервис заказов
5. Предполагая, что появятся и другие задачи на подтверждение заказа, избавляемся от связанности
Вместо команды шлем событие (заказ_подтверждён(id)) в общую шину.
6.Теперь при любых добавлениях обработки сервис заказов не меняется.
Сервис заказов больше ничего не знает об обработчиках — низкая связанность.
7. При этом потеря знания — это и потеря ясности.
Разработчики сервиса заказов могут не знать, кто обрабатывает их событие, и наделать проблем.
Например, поменять структуру события, не предупредив всех заинтересованных лиц.
Сервис заказов больше не зависит от других компонентов, но другие компоненты все еще зависят от него.
8. Для возвращения ясности мы можем вернуть команды.
Однако, информация об этом в сервисе не сохранилась. Нужно проводить анализ. И не факт, что аналитики смогут отследить все варианты использования нашего события.

Завис на выборе задачи под пример декомпозиции (

- Задача должна быть более-менее знакомой (чтобы не зависнуть на этапе первого представления)
- Задача должна быть относительно простой (чтобы не разбирать ее неделями)
- Задача должна быть достаточно сложной (чтобы решение не было тривиальным, и включало как можно больше техник)

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

То есть примерно так:
Как бы я спроектировал PowerPoint вернувшись на 25 лет назад.

Если есть интересные идеи - накидайте, пожалуйста. )

Презентация по одной хорошей книжке Влада Хононова (Vladikk).

Повозился немного с Яндекс GPT.
Vision системы за полчаса )

Странная ADR

Я видел достаточно много ADR, описывающих решения по проектированию системы.
Но мне очень редко попадались обоснования выбора того или иного архитектурного метода/подхода.
Архитекторы либо не желают рассказывать о своих методах, либо считают, что здесь никаких альтернатив не существует, и говорить, в сущности, не о чем.

Я решил не придерживаться общей традиции и начать декомпозицию с объяснений.
https://telegra.ph/ADR-2410201-10-20

Выбранный метод структуризации системы
(выжимка из лонгрида)

1. Структурируем транзакции, разбивая их по компонентам.
2. Проводим структуризации итерационно.
3. На каждой итерации определяем критерий сцепленности транзакций. Например, на первой итерации сцепленными будут транзакции, принадлежащие единому доменному языку.
4. Под сцепленные транзакции формируем компонент.

P.S. Если какая-нибудь вредная транзакция не захочет ложиться в наши компоненты, и мы ради нее не захотим менять структуру, то
разбиваем эту транзакцию на куски и делаем из нее сагу.

ScyllaDB | Thank You
https://lp.scylladb.com/designing-data-intensive-apps-book-thanks

Клеппманн раздаёт бесплатно избранные главы из своей знаменитой книжки (с кабанчиком). Если еще не приобрели - рекомендую )

Метрика сцепленности по языку

Когда-то я был одержим автоматизацией контроля качества работы. На все пытался накинуть фитнес-функцию с соответствующей метрикой.

Задача: определить, что границы между контекстами проведены верно. То есть внутри контекста функции сцеплены по языку сильно, а между контекстами слабо.

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

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

2. Далее я решил сравнивать по свойствам сущностей (атрибутам и методам). Чем больше общих свойств - тем ближе должны быть функции.

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

Так как мапить мне было лень, на этом идея выдохлась (

Возможно у подобного подхода есть потенциал. Оставлю здесь. Надеюсь еще пригодится )

Качества архитектуры
«Вначале была модель» (Книга, И:1:1).

Рассмотрим архитектуру как Большую Модель,
то есть множество моделей системы, описанных разными языками.

Какими качествами должна обладать эта модель?

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

Я же вслед за М. Фаулером и Джорджем Боксом считаю, что модель не может быть правильной или неправильной.
Она может быть полезной или бесполезной:
- «Models are not right or wrong; they are more or less useful» (Martin Fowler).
- «В сущности, все модели неправильны, но некоторые полезны» (George E. P. Box).

2. Полезность
Полезность модели — вопрос интересный.
Том ДеМарко считает, что любая, даже очень простая модель может принести пользу.
Достаточно того, чтобы модель предсказывала что-нибудь хоть чуток наперёд и хоть чуточку точно.

Однако это не даёт ответа на вопрос, стоит ли, например, строить сложную мат. модель производительности или можно обойтись простыми предположениями.
Насколько «полезной» должна быть модель?

Меру полезности, неожиданно, предлагают менеджеры, представляющие буржуазию.
У них это называется «выгода» .
Если прибыль от модели будет выше, чем затраты на её производство и поддержку, то модель безусловно полезна.

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

3. Истинность
И. Ньютон, нисколько не смущаясь, обосновывал истинность своих гипотез их пользой -
«Теория работает, значит она верна» .
Ньютону вторят Басс, Клемантс и Казман: «The right architecture paves the way for system success» .
И даже у Владимира Ильича близкое: «Теория Маркса верна, так как она всесильна» .

Я, вслед за Декартом, с подозрением отношусь к этому подходу.
Это опять нас притягивает к понятию «правильной модели» .

Остановлюсь на архитектурном эквиваленте истинности — целостности.
Пусть модель будет внутренне непротиворечивой — этого достаточно.

4. Полнота
Сразу нет!
Во-первых, это дорого.
Во-вторых, не нужно.
В-третьих, недостижимо (спасибо за разъяснения Геделю).

5. Красота
Модель должна быть красивой.
Зачем — не знаю.
Говорят, красивый инструмент повышает продуктивность. Возможно.
Как оценить красоту, тоже не знаю.
У меня есть только одна метрика для этого качества — лаконичность.

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

Остальное — блажь )