State — изменение поведения объекта в зависимости от его состояния

Паттерн State позволяет объекту менять своё поведение при изменении внутреннего состояния, заменяя громоздкие конструкции из условных операторов на структурированный набор состояний.

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

State применяется в моделях процессов, конечных автоматах, агрегатах DDD, жизненном цикле сущностей, оркестрации операций, API workflow и сложной бизнес-логике с динамическими этапами.

Паттерн State является одним из ключевых инструментов архитектора, когда бизнес-логика зависит от статуса, стадии или жизненного цикла объекта. Вместо того чтобы писать десятки условных конструкций, State предлагает вынести каждое состояние в отдельный объект (или модуль), а переходы между состояниями реализовать как контролируемый механизм.

Главная идея

State превращает объект в конечный автомат:

• у объекта есть текущее состояние;

• каждое состояние определяет, какие операции доступны;

• при вызове метода состояние может измениться;

• логика операций зависит от текущего состояния.

Таким образом, объект меняет своё поведение «на лету».

Где State применяется в архитектуре

1. Жизненный цикл сущностей (DDD)

Например, агрегат «Заказ» может иметь состояния:

• Created

• Paid

• Packed

• Shipped

• Delivered

• Cancelled

В каждом состоянии доступен свой набор операций:

• из Created можно отменить,

• из Shipped отменить уже нельзя,

• из Paid нельзя добавить товары, и т.д.

State делает такую модель прозрачной:
каждое состояние = отдельный объект со своим набором правил.

2. Workflow и бизнес-процессы

Каждый шаг workflow — это состояние:

• «На согласовании»

• «Отклонено»

• «Одобрено»

• «В ожидании данных»

• «Выполнено»

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

3. Интеграционные процессы

Подходит для:

• многостадийной обработки данных;

• последовательности шагов;

• retry-механизмов;

• оркестрации сервисов.

Состояние запоминает, на каком шаге процесс остановился, и какое поведение следует дальше.

4. Авторизация и безопасность

Модели сессий, пользователей, токенов, политик доступа:

• Anonymous

• Authenticated

• Privileged

• Expired

• Locked

Каждое состояние определяет свой набор доступных операций.

5. API workflow и протоколы взаимодействия

Например, протоколы, которые требуют строго определенного порядка действий:

• INIT → AUTH → PROCESS → COMPLETE

State полностью управляет этой последовательностью.

Преимущества State для архитектора

1. Устраняет хаос условных операторов

Без State всё превращается в:

if (status == A) {…}

else if (status == B) {…}

else if (status == C) {…}

Что становится неуправляемым.

State заменяет это на:

• класс состояния A

• класс состояния B

• класс состояния C

И всё.

2. Добавление новых состояний без переписывания старых

Нужен новый статус?
Просто создается новый объект-состояние.

3. Четкая архитектурная модель

• проще читать;

• проще тестировать;

• проще документировать;

• проще объяснять бизнесу.

4. Природная поддержка конечных автоматов

State = паттерн для архитектурного проектирования FSM (Finite State Machine), что используется во всех серьёзных системах.

Типичные ошибки и как их избежать

• слишком много состояний → группируйте в подмодели;

• состояния с большой логикой → каждая ответственность должна быть четкой;

• неявные переходы → переходы должны быть видны и документированы;

• несогласованность логики в разных состояниях → соблюдайте инварианты агрегата.

State в учебниках по архитектуре ИС

State рассматривается в разделах:

• жизненные циклы бизнес-объектов;

• состояния процессов;

• автоматизированные системы управления;

• модели конечных автоматов;

• динамическое поведение сложных систем.

То есть паттерн фундаментален для дисциплины «Архитектура ИС».

Почему архитектор обязан знать State

Потому что 70% бизнес-систем строятся вокруг процессов и состояний: заказы, заявки, документы, платежи, workflow, pipeline, интеграции.
State позволяет проектировать такие модели грамотно, без избыточной связанности и хаоса в коде.

Архитектор, владеющий State, умеет:

• проектировать жизненные циклы;

• описывать поведение агрегатов;

• фиксировать инварианты и допустимые переходы;

• предотвращать противоречия в логике;

• создавать устойчивые и расширяемые системы.