#temporal
#system_design
#requirements
Так-с, ну вот ещё одна :)
Несмотря на то, что в заголовке фигурирует Temporal, это не совсем статья про Temporal. Это материал про проектирование систем. Про то, как превратить неструктурированные хотелки в формальные требования, не потерять здравый смысл по пути, заложить архитектурный фундамент и не пожалеть об этом через месяц. Ну и спроектировать workflow на Temporal, конечно же :)
В этой части я попробовал описать анализ требований в новом формате — с живыми диалогами, структурированными каталогами и архитектурными выводами прямо на ходу.
Интересно будет узнать в комментариях, насколько такой стиль заходит. Особенно от тех, кто осилит статью до конца (а статья получилась довольно большой, пришлось даже ужимать - надеюсь, что не в ущерб качеству) :)
—
📖 Часть 1 — «Анализ требований» — уже доступна:
Temporal: Deep Dive. От требований до workflow: проектируем биллинг с оркестрацией.
В этой статье мы отойдём от абстрактной теории и наконец-то займемся чем-то интересным. Вместо обсуждения надуманных примеров, мы возьмём вполне реалистичную задачу для огромного количества (не финтех) компаний — обработку платёжных транзакций. Вместе мы попробуем пройти весь путь: от первых продуктовых обсуждений до готовой системы, часть которой реализована с помощью Temporal Workflow.
Мы начнём с того, что трансформируем неструктурированные хотелки в формализованные требования: функциональные, нефункциональные и бизнес-правила. Затем мы разберёмся с особенностями интеграции с платёжным шлюзом и ограничениями, которые она накладывает.
После этого — обсудим архитектурные решения, объясним, почему для оркестрации мы выбрали именно Temporal, и, наконец, покажем, как перейти от идей и диаграмм к коду — включая тестирование, наблюдаемость и поддержку изменений.
Готовы? Поехали!
#system_design
#requirements
Так-с, ну вот ещё одна :)
Несмотря на то, что в заголовке фигурирует Temporal, это не совсем статья про Temporal. Это материал про проектирование систем. Про то, как превратить неструктурированные хотелки в формальные требования, не потерять здравый смысл по пути, заложить архитектурный фундамент и не пожалеть об этом через месяц. Ну и спроектировать workflow на Temporal, конечно же :)
В этой части я попробовал описать анализ требований в новом формате — с живыми диалогами, структурированными каталогами и архитектурными выводами прямо на ходу.
Интересно будет узнать в комментариях, насколько такой стиль заходит. Особенно от тех, кто осилит статью до конца (а статья получилась довольно большой, пришлось даже ужимать - надеюсь, что не в ущерб качеству) :)
—
📖 Часть 1 — «Анализ требований» — уже доступна:
Temporal: Deep Dive. От требований до workflow: проектируем биллинг с оркестрацией.
В этой статье мы отойдём от абстрактной теории и наконец-то займемся чем-то интересным. Вместо обсуждения надуманных примеров, мы возьмём вполне реалистичную задачу для огромного количества (не финтех) компаний — обработку платёжных транзакций. Вместе мы попробуем пройти весь путь: от первых продуктовых обсуждений до готовой системы, часть которой реализована с помощью Temporal Workflow.
Мы начнём с того, что трансформируем неструктурированные хотелки в формализованные требования: функциональные, нефункциональные и бизнес-правила. Затем мы разберёмся с особенностями интеграции с платёжным шлюзом и ограничениями, которые она накладывает.
После этого — обсудим архитектурные решения, объясним, почему для оркестрации мы выбрали именно Temporal, и, наконец, покажем, как перейти от идей и диаграмм к коду — включая тестирование, наблюдаемость и поддержку изменений.
Готовы? Поехали!
🔥14❤2