Мартин Фаулер, международный эксперт по программной инженерии, начал свою публичную просветительскую деятельность с книги Analysis Patterns 1997-го года.

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

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

Андрей Гордиенков решил исправить это досадное обстоятельство и подготовил собственную версию перевода.

https://habr.com/ru/articles/872598/

Вступление
1.1 Концептуальные модели
1.2 Мир шаблонов
1.3 Шаблоны в этой книге
1.4 Концептуальные модели и реинжиниринг бизнес-процессов
1.5 Шаблоны и фреймворки
1.6 Использование шаблонов

Часть 1. Аналитические шаблоны
2. Ответственность
3. Наблюдения и измерения
4. Наблюдения для корпоративных финансов
5. Обращение к объектам
6. Инвентаризация и учет
7. Использование моделей учета
8. Планирование
9. Торговля
10. Производные контракты
11. Торговые пакеты

Часть 2. Поддерживающие шаблоны
12. Слоёная архитектура для ИС
13. Фасады приложения
14. Подходы для моделирования типов
15. Шаблоны ассоциации
16. Послесловие

Часть 3. Приложения
А. Техники и обозначения
В. Таблица паттернов
C. Краткая справка по диаграммам

Сколько вы знаете способов передачи данных на клиент по инициативе сервера?

В комментариях к предыдущему посту отмечают, что GraphQL не совсем верно упоминать рядом с Websockets, это вещи разного уровня. Давайте разберемся, и вспомним все варианты отправки данных с на клиент в тот момент, когда их решил отправить сервер.

Я насчитал 6 (добавляйте, если знаете ещё):

1. Long polling — обычный http-запрос, но сервер дает ответ только в тот момент, когда у него появились/изменились данные. Если данные не появились до истечения таймаута, соединение разрывается, но клиент тут же его восстанавливает. После получения ответа соединение тоже восстанавливается.

2. WebHooks — по сути, обратный вызов http. Серверу каким-то образом нужно сообщить адрес эндпоинта клиента и код события, по наступлении которого нужно этот эндпоинт вызвать. Сообщить можно через настройки, а можно через специальное API. В терминах языков программирования — это callback. Когда на сервере произойдет событие, он вызовет ваш эндпоинт.

3. WebSockets — отдельный протокол, первоначальное соединение устанавливается через http, в котором клиент передает хедер upgrade, и дальше уже происходит переключение протокола, и общение идёт через websocket — полнодуплексный канал между клиентом и сервером, где они оба могут пересылать друг другу сообщения (текстовые или бинарные). Очевидные кейсы: чат, многопользовательская игра, совместное редактирование документа/картинки. Отличается от других асинхронных способов получения данных тем, что соединение полнодуплексное — клиент может отправлять данные в том же соединении.

4. Server-Sent Events (SSE) — почему-то редко вспоминают, но это штука, похожая на long polling, только сервер может пересылать несколько порций данных сразу в одном соединении. И это тоже http! Клиент при этом указывает специальный тип контента: text/event-stream (если шлет в веб-браузер) и application/stream+json (если шлет в другой клиент, не в браузер).

5. HTTP/2 streams — бинарный протокол, на базе которого работает gRPC. HTTP/2 в принципе построен на понятии потока, в котором клиент что-то запрашивает, а сервер что-то шлет в ответ... Так что идея полнодуплексного обмена появляется почти автоматически — почему бы серверу в том же потоке не слать данные по собственной инициативе.

6. HTTP/3, который QUIC — примерно то же, что и HTTP/2 — на уровне использования приложением, все различия внутри: он на основе UDP, а не TCP, что дает ряд преимуществ, в основном в скорости. Подробнее про HTTP разных версий можно почитать тут. В двух словах — борьба идет за число открытых соединений с сервером: в HTTP/1.0 соединение обрывается после каждого ответа сервера, в HTTP/1.1 появился заголовок keep-alive, сохраняющий TCP соединение, в HTTP/2 много соединений TCP от клиента к серверу объединили в одно, а в HTTP/3 вообще перешли на UDP, в котором вообще нет сложного процесса установки соединений.

Разобраться со всеми этими технологиями бывает сложновато, поэтому низкоуровневые протоколы пакуют в инструменты более высокого уровня абстракции — типа того же GraphQL или разнообразных API в браузере (streams API, fetch API, WebTransport) — про которые программисты уже не думают, как они внутри устроены, а просто ими пользуются.

На самом деле, внутри GraphQL либо WebSocket, либо multipart subscriptions over HTTP (ещё один способ, похожий на SSE — когда мы устанавливаем соединение по http, сервер говорит, что будет отдавать multipart/mixed контент, а потом начинает эти части клиенту отдавать по мере появления/изменения).

А  стримминг в gRPC работает по технологии HTTP/2 или HTTP/3, это тоже обертка.

Что в этом для аналитиков? А вот что: кажется, всё идёт к тому, что стили API (REST или RPC) будут больше логическими, а не технологическими. При высокой интенсивности обмена между системами будет просто открываться канал, в котором они будут обмениваться сообщениями, а уж будут эти сообщения устроены вокруг операций с ресурсами, или вокруг вызова функций, или это будет поток сообщений в стиле event-driven — это на логическом уровне будет разбираться приложение.

Есть такое модное понятие, применительно к медиа —фактчекинг. То есть, поиск и проверка источников. У аналитика это должно срабатывать на уровне рефлекса: кто-то сказал — нужно проверить и найти подтверждение, что это действительно так. Особенно интересно бывает найти нормативный документ, и увидеть, что практика с ним серьёзно расходится.

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

Вот из недавнего: чуть ли не в каждой статье про важность soft-skills (особенно от HR-ов или edTech-ов) встречается фраза, причём дословно:
"Ученые из Гарварда, Стэнфорда и Фонда Карнеги выяснили, что «гибкие навыки» — это 85% успеха человека в профессии, жесткие составляют только 15%."

Её, кажется, первым запустил РБК, а потом все стали друг у друга перепечатывать.

Интересно, что такое исследование действительно существует! Но есть нюанс — это исследование 1918 года! Не опечатка — 1918, более 100 лет назад. В исследовании американским инженерам задавали вопрос: что им больше всего помогает при выполнении проектов? И они отвечали, что твердость характера. Такой вот софт-скилл. Другие упоминаемые качества: ясность суждений, производительность, понимание людей и широта знаний. Такой набор, а не то, что сейчас под софт-скиллами понимается — типа, быть милым, эмпатичным и поддерживать нетворкинг.

То есть, с одной стороны, любопытно, что исследования эти ведутся ещё с XIX века (в том журнале есть ссылки и на исследования 1880-х годов), но неужели нет более свежих работ? И правда ли мы сейчас собираемся опираться на опыт американских инженеров времён Первой мировой? Впрочем, качества-то перечислены полезные.

🧐Вон Вернон, написавший известную красную книжку про DDD Реализация методов предметно-ориентированного проектирования (а потом и зеленую книжку с подзаголовком Самое основное), пару месяцев назад запустил видеоблог под названием Design Accelerator

Недавнее видео Publishing Events From Legacy показалось мне примечательным. С технической точки зрения вы вряд ли узнаете в нем что-то новое. Но вот то, что DDD появляется в контексте модернизации унаследованных приложений, кажется мне интересным фактом. Похоже, мы возвращаем к дискуссии про Monolith First

Пару недель назад у Ivar Jacobson появилась бумага с названием Use-Case 3.0 и даже прошел вебинар (запись можно посмотреть здесь)

Я напомню, что концепция Use-Case 2.0 была о том, как организовать итерационную инкрементальную разработку посредством разделения сложного варианта использования на ломтики (slices) (Почитать можно здесь)

Что принципиально нового принесла версии 3.0 я пока так и не разобрался. Но, несмотря на это, варианты использования à la Alistair Cockburn/Ivar Jacobson остаются полезным способом описания сложных сценариев взаимодействия между системами/сервисами и разного прочего поведения

📃 BABOK Guide уже много лет не обновлялся. Зато на днях появилась вторая версия The Business Analysis Standard. Скачать стандарт можно по ссылке выше ☝️, при желании, предварительно зарегистрировавшись здесь

🔖 Что поменялось (сжатый анонс от авторов):
- Оптимизирован язык для более легкого понимания и навигации
- Области знаний реорганизованы в соответствии с BABOK Guide. Согласована терминология стандарта и руководства
- Стили документа приведены в соответствие со стандартами ISO
- Для быстро ознакомления со стандартом добавлен общий обзор
- Новые и расширенные разделы: ценность и результаты (outcomes and value), организационные соображения, улучшения и проработка идей

🖇 Как всё это связано с архитектурой решений. В какой-то момент IIBA стал максимально широко трактовать бизнес-анализ, захватив заметный кусок solution architectгure. Вряд ли это правильно, но зато, пока у солюшенов нет своего стандарта, в какой-то мере, можно воспользоваться стандартом аналитиков (а не только стандартами архитекторов предприятия)

ℹ️ В прошлом году неожиданно обновилось до 4 версии руководство по программной инженерии SWEBOK (The Guide to the Software Engineering Body of Knowledge) Предыдущая версия руководства была выпушена в 2014, а первая версия появилась в 2004.

🆕 Еще более неожиданным является то, что к 15 областям знаний, описанным в SWEBOK ранее, добавились три новых: Software Engineering Operations, Software Security и (сюрприз-сюрприз) Software Architecture. При этом область знаний Software Design, существовавшая в предыдущей версии, тоже сохранилась.

⬇️ Загрузить руководство можно по ссылке выше. Русскоязычный обзор новой версии SWEBOK можно почитать в журнале Открытые системы. СУБД