Микросервисы / распределенные системы

2021-05-29 17:59:51 Есть идеальный код, а есть просто хорошо структурированный

Так вот, идеальный код — практически невозможно писать (но можно стремиться). При пересмотре через месяц — всегда придумаешь как его можно было бы улучшить, или решить проблему более гибко/элегантно.

Структурированный, чистый, читаемый код — это код, который может быть «тупым», но легко понимаемым и читаемым. Возможно он не даст гибкости, но он позволит быстро найти ошибку в логике программы. И исходя из этого посыла НЕ СУЩЕСТВУЕТ причин, не писать хорошо структурированный код.

Статья от нетфликс о hexagonal architecture: https://netflixtechblog.com/ready-for-changes-with-hexagonal-architecture-b315ec967749

Рассуждения Саймона Брауна на тему организации кода: https://www.codingthearchitecture.com/2016/04/25/layers_hexagons_features_and_components.html

Кому интересна история - первая статья о hexagonal architecture (Alistair Cockburn): https://archive.is/5j2NI
Для любителей видео: https://www.youtube.com/playlist?list=PLGl1Jc8ErU1w27y8-7Gdcloy1tHO7NriL Открыть/Комментировать

2021-05-03 13:47:22 Фейсбук напомнил о написанном 5 лет назад :) Легаси Стрит :)

Когда мы говорим о том, какими микросервисы должны быть с концептуальной точки зрения, мы всегда держим в уме и повторяем как мантру: «слабая связанность» и «сильное сцепление». Всегда.
И маршируя по Legacy Street за переход к более гибкой архитектуре, на наших транспарантах будут именно словосочетания «слабая связанность» и «сильное сцепление» :)
Что главное? Возможность внесения изменений и развертывание сервиса без необходимости внесения изменений в любую другую часть системы. Оно же — Low Coupling.
Сильное сцепление (High Cohesion) — я, как кем бы я ни был, хочу, чтобы связанное поведение находилось в одном месте, внутри некой границы, которая имела бы как можно более слабую связь с другими границами.
Вот тут появляется ограниченный контекст (Bounded Context) или иначе — конкретная ответственность, обеспечиваемая четко обозначенными границами.
И если мы хотим перейти от монолита к микро, то мы сначала очень аккуратно выделяем контексты, определяем модель (внутреннюю для контекста), повышаем модульность системы. Уверены? Выносим модуль в сервис.
И думаем о сервисах в терминах бизнес-возможностей. Сначала «Чем контекст (модуль, сервис) занимается и какие услуги предоставляет?», затем «Что (какие данные, внутренние или из других контекстов) ему нужны?» Открыть/Комментировать

2021-04-27 00:01:10 На фото происходит ровно то, что написано, без двусмысленных толкований Открыть/Комментировать

2021-04-21 20:02:21 Открыть/Комментировать

2021-04-17 00:24:52 По ссылке — видео выступления для SpbDotNet на тему «Event Storming: избавляемся от предположений в коде» от 14 апреля. Видео на два с половиной часа =)
http://agilemindset.ru/event-storming-избавляемся-от-предположений/ Открыть/Комментировать

2021-04-12 22:15:16 Достаточно свежая, очень классная книга по теме Security Chaos Engineering. Открыть/Комментировать

2021-04-09 12:39:57 Немного необычные статьи про масштабирование по аналогии IKEA =)

https://codesensei.medium.com/http-request-and-response-and-how-web-applications-work-76780d4cb14c
https://codesensei.medium.com/how-to-scale-a-web-application-to-handle-infinite-amount-of-traffic-b3f3028bd923 Открыть/Комментировать

2021-04-04 14:26:11 Очень много материалов по кликхаусу: https://presentations.clickhouse.tech/talks_index.html Открыть/Комментировать

2021-03-25 21:44:39 Рейтинг баз данных по популярности. Может пригодиться как одно из измерений в выборе БД под потребности конкретного сервиса.
https://db-engines.com/en/ranking Открыть/Комментировать

2021-03-25 21:16:26 “Don't build elaborate APIs that mimic the back-end system's design. Instead, build consumer-driven APIs that provide the service in a format that the front-ends prefer.” (с) Gregor Hohpe, Cloud Strategy

При проектировании API учитывайте контекст, в котором сущность используется.

Вместо всеобъемлющего
GET /product/123

Используйте хотя бы контексты
GET /catalog/product/123
GET /checkout/product/123
GET /someothercontext/product/123

С теми атрибутами, которые нужны в заданном контексте. Эту рекомендацию можно использовать и в монолите, в микросервисах же она жизненно-необходима.

Если пойти дальше, в DDD (например через event storming), то API изменятся еще сильнее и станут отражать поведение, а не сущности:
/GetAvailableProducts
/GetProductDeliveryOptions
/GetProductsAtSale

Такие API удобно развивать, они обеспечивать минимальную связанность и максимальное сцепление.

Проверим от противного
Три Use Cases:
- Отобразить доступные на складе продукты
- Отобразить варианты доставки продукта
- Получить список продуктов, участвующих в распродажах

В случае реализации трех сценариев с использованием метода /product/123 мы получаем зависимость всех трёх от одного API. Потребность в изменениях для одного приведет к необходимости координации изменений со всеми остальными. В случае API, определяемых от поведения таких зависимостей нет. Открыть/Комментировать