Пятничное чтиво

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

—————————————

The First 10-Year Evolution of Stripe’s Payments API

Очередная статья «как в компании X решали проблему Y». На этот раз это страйп, который решал проблему развития собственного API. Может показаться, что около 10 строк кода — легко поддерживаются. Но на деле, за строками скрываются десятки стран, в каждой из которых собственные законы, банки и способы оплаты. Статья выше описывает 4 этапа развития компании (с 2011 по 2020 года).

Первый этап с 11 по 15 года, когда появилась концепция «токена». Т.е. вместо того, чтобы отправлять информацию о карте в магазин, данные отправлялись из браузера на сервера страйпа, возвращался токен и с этим токеном можно было работать (этот лайфхак сам использую для работы с персухой).

Второй этап с 15 по 17 года. Тут появляются новые способы оплаты (что усложняет API). Тут возникла проблема с асинхронными платежами и отслеживанием платежей со стороны продавцов.

Третий этап с 17 по 18 года посвящен решению проблем со второго этапа. В результате появился универсальный API для любого из видов платежей. Тут же появляются новые абстракции и правила к API.

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


#how_it_works #payments

—————————————

Being an architect isn’t the sum of skills. It’s the product.

Статья от автора книги Architect Elevator, в которой рассуждается о смысле архитекторов как о роли. Связано с тем, что software systems уже давно не technical, а socio-technical systems (тут должна быть отсылка на ТТ), что подтверждается переходом на service модели (это о бизнес услугах, а не о микросервисах).

Статья начинается с утверждений вокруг «важности» восприятия IT как socio-technical systems. Далее автор вспоминает девиз консалтинговых компаний «people, process, technology» и через него объясняет где находится роль архитектора. Что приводит к мысли о том, что роль — множитель, а не addition (не добавляет ценность, а умножает то, что есть). Далее приводится три примера этого утверждения: объяснение другим тех решений, руководство тех командой и платформы.

#architect_role

—————————————

When Should I Write an Architecture Decision Record

Если открыть статью об ADR, то в 90% случаев в тексте найдете пример шаблона, какие инструменты использовать и где/как хранить документы. Текст выше попадает в оставшиеся 10%, так как затрагивает вопрос: «когда писать ADR, а когда можно забить?».

Начинается статья с преимуществ, которые получил Spotify (музыкальный стриминг) при внедрении ADR. Сюда попал онбординг, помощь с передачей ответственности за части системы и унификацию решений для разных команд. Далее описывается когда документ нужен (когда «решение имеет существенное влияние»). Так как «существенное влияние» субъективный термин, авторы описали три ситуации, в которых стоит задуматься:
- Присутствует проблема, решение которой известно, но нет задокументированного описания этого;
- Появляются изменения, которые приводят к изменению на стороне клиентов (как пример). Тут советуют сначала RFC написать, потом думать об ADR;
- Незначительные решения, которые могут повториться в другой команде;

Из минусов — было бы круто, если бы в тексте были примеры, когда не стоит писать ADR.

#adr