Коротко о главном: максимально субъективный взгляд на IT, технологии и архитектуру

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

Welcome в dpr/dev space !

PS: (токсичным) Желающим похоливарить про кафку тут всегда рады.


Полезные теги для поиска

#orchestration
#distributed_transactions
#temporal
#security
#auth
#dotnet
#efcore
#db
#db_design
#dwh
#system_design
#api_design
#infrastructure

#api_design
#system_design

Дизайн API: Как быть, когда есть множество потребителей

Хотя я начал писать о Temporal, решил отвлечься на другую тему, которая с ним мало связана: дизайн API.

В предыдущей статье о Temporal мне задали несколько вопросов о непонятном атрибуте в названии URL, который встретился в тексте прошлой статьи [HttpPost("system.clients.startUserGrantedWorkflow")]. Вопрос был вызван наличием группы system в URL адресе.

Решил пролить свет на эту тему и описать, зачем мы составляем URL-адреса такого вида, чем это обусловлено и какие последствия это может иметь для всего проекта.

Дизайн API: Как быть, когда есть множество потребителей

#temporal
#system_design
#requirements

Так-с, ну вот ещё одна :)

Несмотря на то, что в заголовке фигурирует Temporal, это не совсем статья про Temporal. Это материал про проектирование систем. Про то, как превратить неструктурированные хотелки в формальные требования, не потерять здравый смысл по пути, заложить архитектурный фундамент и не пожалеть об этом через месяц. Ну и спроектировать workflow на Temporal, конечно же :)

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

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

—

📖 Часть 1 — «Анализ требований» — уже доступна:
Temporal: Deep Dive. От требований до workflow: проектируем биллинг с оркестрацией.

В этой статье мы отойдём от абстрактной теории и наконец-то займемся чем-то интересным. Вместо обсуждения надуманных примеров, мы возьмём вполне реалистичную задачу для огромного количества (не финтех) компаний — обработку платёжных транзакций. Вместе мы попробуем пройти весь путь: от первых продуктовых обсуждений до готовой системы, часть которой реализована с помощью Temporal Workflow.

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

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

Готовы? Поехали!