Пятничное чтиво Старые записи стримов можно найти на ютубе. Т | 2pegramming

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

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

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

Размер микросервиса

Хоть статья, в названии, говорит о размере микросервиса, текст ценен примерами границ этих сервисов, описанных ближе к концу. Список вариантов изоляций выглядит следующим образом:

- Изоляция по бизнес потребностям - границы проводятся по заветам DDD, т.е. по бизнес процессам, коммандам, bounded context, , etc. При этом, использование event storming может помочь найти границы;
- Изоляция состояния - система разделяется по данным, с которыми работает до тех пор, пока 2+ серивса не начнут в одну базу ходить или использовать распределенные транзакции;
- Изоляция в пространстве - не очень понял идею, если кто-то поймет, объясните пожалуйста в комментариях;
- Изоляция во времени - если нужна транзакционность для поддержания согласованности данных - лучше такие части объединять;
- Изоляция сбоев - падение одного сервиса не влияет на другие;

#service_boundaries

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

Top 10 Architecture Characteristics / Non-Functional Requirements with Cheatsheat

Архитектурные характеристики (non-func requirements, quality attributes) являются частью системы, благодаря которой можно принимать технические, дизайн и архитектурные решения. Например: в двух одинаковых по функционала блога за 15 минут, один блог должен обрабатывать 10k запросов в секунду, другой - 5 запросов. В таком примере, дизайн и архитектурные решения будут отличаться, при том, что функционал и форма блогов будет абсолютно одинаковой.

При этом, характеристик много и помнить каждую - сложная задача. Поэтому, автор решил описать 10 самых популярных характеристик. Для каждой дается краткое описание, описываются подвиды и иногда даются примеры дизайн паттернов, которые могут помочь с характеристикой. Еще есть диаграмма, на которой характеристики собираются в одну картинку.

#architecture_characteristics

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

Tactical Forking

Если верить авторам Software Architecture: The Hard Parts, существует два варианта архитектурной декомпозиции монолитов:

- component-based
- tactical forking

Первая предполагает выявление компонентов и постепенный перенос компонентов из монолита в отдельный сервис (5 глава книги, там шесть шагов).

Но сегодня статья о втором варианте. Идея заключается в копировании системы 1 в 1 как новый сервис, после чего не нужный код удаляется до тех пор, пока не останется только необходимый функционал в каждом из сервисов. Это похоже на создание скульптур из мрамора, когда итеративно отсекается лишнее. Главный плюс подхода, по заверению автора, позволяет разбить big ball of mud на сервисы.

Вроде как, первым, подход описал Fausto De La Torre, статью которого можно найти по ссылке.

#monolith_decomposition

——— одной строкой ———

- В четверг прошло интервью с Мартином Клеппманном, это автор Designing Data-Intensive Applications (DDIA), запись еще не выложили, но она должна появиться на канале книжного клуба