Два основных элемента:
Аутентификация - проверка того кем является пользователь, т.е. по сути проверка личности
Авторизация - проверка того, что пользователь может сделать

Вспомогательные процессы:
- аудит - это логировние данных, позволяющих восстановить порядок действий, которые выполнил пользователь. Используется для расследования нештатных ситуаций
- шифрование - основной способ сокрытия данных от доступа третьих лиц
- лимитирование - лимиты, как правило основаны на ограничении доступа к ресурсам. Но бывает и лимиты времени. Это позволяет противостоять атакам "грубой силы", когда у атакующего есть огромные вычислительные ресурсы.

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

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

Современное состояние Data Science

Частенько встает вопрос о различии ML и DS, эта картинка хорошо показывает и различия, и состояние дел на сегодняшний день.

В решении своих задач DS, если смотреть обобщенно, использует:
- Визуализацию
- Хранение данных
- Структурирование данных
- Математические методы
- Языки программирования
- Решения для машинной обработки данных (ML)

Т.е. ML - это одно из направлений DS.

ML же занимается:
- обучением с подкреплением
- компьютерным зрением
- Deep Lerning
- системами рекомендаци
- обучением с учителем
- обучением без учителя
- и т.д.

перезалью в нормальном качестве

Вывод: ML - это конкретно методы обработки данных (в том числе и интеллектуальные), а DS - это общее направление, в которое входит весь спектр решения задач по обработке, хранению и визуализации данных.

Если меня попросят порекомендовать flow для разработки проекта, то пожалуй это будет Trunk based + Feature flag + Branch by abstraction

на изображении схематично показан алгоритм работы trunk flow, из плюсов:
- простой и легкий
- подходит для частых релизов и CI
- не имеет проблем "длинных" слияний (когда ветка долго в разработке находится)

Идея простая - есть одна основная ветка (trunk) весь код непрерывно сливается в нее, чтобы отсечь неработоспособные фичи (те фичи, которые находятся в разработке) используются флаги.

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

По всем flow можно посмотреть конспект для архитектурных стримов: https://s0er.ru/codelabs/arch_stream_15/index.html#0

API стили:
- Remote Procedure Call (RPC) - удаленный вызов процедур, один из самых используемых стилей при построении API. Он реализуется с помощью клиент-серверного шаблона архитектуры, и позволяет клиенту выполнять свой код удаленно на сервере.
Обычно используют компактные бинарные форматы. Пример: gRPC ( https://grpc.io ), из более ранних примеров - SOAP

- Remote method invocation (RMI) - вариант RPC который "скрывает" удаленную природу вычислений и со стороны клиента выглядит так, будто вычисления выполняются локально.

- REpresentational State Transfer (REST) - набор прицнипов для построения легковесных API, как правило использует текстовый формат для обмена сообщениями (JSON, XML). Текстовый формат сообщений позволяет развязать зависимости сервера и клиента, не использовать какие-либо общие библиотеки. Унифицирован для веб-разработки.

- специализированные API - как правило API построенные на каком либо языке запросов, которые разрабатываются конкретно под сервер. Пример: SQL.

Доступ к API обычно осуществляется по следующей схеме