Two-factor authentication (2FA) или Двухфакторная аутентификация. Более подробно читаем про Двухфакторная аутентификация.
Backlog (Бэклог) — это список задач, требований или элементов работы, которые необходимо выполнить в будущем. Обычно используется в управлении проектами, особенно в гибких методологиях. Подробнее читаем о Бэклог
Big Design Up Front или BDUF Этот принцип разработки программного обеспечения утверждает, что разработчик должен сначала завершить проектирование, а после этого проект можно начинать реализовать.
Сторонники утверждают, что такой подход помогает обнаруживать проблемы на стадии требований и быстро и дёшево их решать.
Однако изменения в требованиях к программному обеспечению могут произойти в течение жизненного цикла проекта. Очень редко требования остаются неизменными на протяжении всего жизненного цикла проекта.
Это расшифровывается как Business Layer или Уровень бизнес логики. Более подробно читаем в Business Layer
Blue Team (Синяя команда) — это группа специалистов по информационной безопасности, задача которой — защищать организацию от кибератак, обнаруживать вторжения и реагировать на них. В отличие от Red Team, которая атакует, Blue Team играет оборонительную роль.
Задачи команды:
1. Обучение сотрудников
Повышение киберграмотности персонала, защита от фишинга и других методов социальной инженерии.
2. Мониторинг и анализ событий
Использование SIEM-систем (например, Splunk, ELK) для отслеживания подозрительной активности в реальном времени.
3. Обнаружение угроз (Threat Detection)
Идентификация признаков компрометации (IoC), аномалий и поведения, характерного для атак.
4. Реагирование на инциденты (Incident Response)
Быстрое принятие мер при обнаружении атаки: изоляция систем, расследование, устранение последствий.
5. Укрепление безопасности (Hardening)
Настройка и обновление систем, политики доступа, контроль уязвимостей, бэкапы и патчи.
6. Форензика (Digital Forensics)
Анализ инцидентов постфактум для понимания механизма атаки и устранения слабых мест.
Есть такой подход – слоёная архитектура, когда код делят на слои. В этой архитектуре BL – это Business Layer или более полно можно сказать Business Logic Layer – уровень бизнес логики. Здесь вы должны писать весь код, который относится к логике приложения.
За счёт отдельного слоя его проще будет тестировать отдельно от данных и разделять между приложениями разного типа – веб или мобильными приложениями.
Более подробно я подобные вещи показываю в своих примерах на практике. Можно много пытаться рассказать о том, как делить и что делить, но лучше увидеть слои на реальных примерах, что я показываю в своих практических примерах в разделе Roadmap.
Command Query Responsibility Segregation (CQRS) — это архитектурный паттерн, при котором запросы (queries) и команды (commands) обрабатываются раздельно, часто — даже разными моделями данных. Подробнее тут CQRS
Command Query Separation (CQS) — это принцип проектирования, предложенный Бертраном Мейером (автором языка Eiffel), согласно которому методы объекта должны быть либо командой, либо запросом, но не одновременно. Более подробно тут CQS
CQRS (Command Query Responsibility Segregation) — это архитектурный паттерн, при котором запросы (queries) и команды (commands) обрабатываются раздельно, часто — даже разными моделями данных.
CQRS предлагает разделить ответственность:
Commands (команды) — изменяют состояние системы (например, «создать заказ», «удалить пользователя»).
Queries (запросы) — только читают данные, не изменяя их (например, «получить список заказов»).
Этот паттерн основан на принципе, что чтение и запись имеют разные требования, поэтому можно оптимизировать каждую часть отдельно.
Допустим, у вас интернет-магазин:
Команда:
POST /orders
{
"userId": 123,
"items": [1, 2, 3]
}
создаёт заказ.
Запрос:
GET /orders?userId=123
возвращает список заказов пользователя.