Components

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

Специфика обработки позволяет выделить несколько видов компонентов.

Stateless

Port

Сервер для внешних систем. Принимает Query из вненего мира и преобразует его в Message (обычно Command), отправляет на обработку. Если требуется, готовит Result (обычно из Event или Error) и отправляет его в ответ на запрос.

Adapter

Клиент для внешних систем. Принимает Message (обычно Command) из приложения и выполняет по нему запрос во внешнюю систему. Если требуется, обрабатывает ответ внешней системы и преобразует его (обычно в Event, Error или, реже, Effect).

Router

Управляет коммуникацией внутри приложения и модулей по данным из Message. Предполагается, что сам раутинг дешев по сравнению с выполнением операции в обработчике. Отдельно выделяются:

• Type discriminator - связывает тип Message и его единственный обработчик, обеспечивает возможность статического связывания компонент между собой.
• Query DSL - на основе разбора URL (сегменты, параметры в сегментах) и на основе параметров сообщения.

Service

Общее название для всех компонентов, которые непосредственно обрабатывают сообщения. Как правило из Command в Event/Error/Effect

Stateful

Memory

Поток происходящего в системе в виде пар Command -> Message. Память может быть как у приложения целиком, так и у модулей и отдельных компонент.

Aggregate

Обычно-понимаемое состояние как компонент. Фундаментально, агрегат состоит из функции-обработчика (Command, ActualState) => (NewState, Effect+) и непосредственно хранилища - переменной или элемента в коллекции. Заданная функция позволяет использовать EventStore (foldLeft!) вместо ORM для надежного хранения данных.

Благодаря Type System приложение может гибко контролировать ЖЦ агрегата. Все задумывается с целью сделать агрегат фасадом над хранилищем с сохранением-по-требованию и возможностью быстро сравнить и восстановить поток событий конкретного агрегата и сам агрегат.

Context

Дополнение для реализации обработчиков вида (Context OldState, Command) => (NewState, Event). Контекст в Request представляет собой набор ID, проверяется в Pipes и наполняется Instance. В вызове должен соблюдаться контракт на иммутательность контекста на время вызова. Все меняющиеся части вызова должны быть помещены в State. ID в контексте можно использовать для организации Pessimistic Locking, выстраивания очередей. Внутри процессов, Context является структурной частью агрегата и не должна меняться, по контракту.

Composite

Projection

Saga

ES

Stack

Cache

Pipes & Drains

Набор обработчиков типовых потребностей прикладного приложения. Предполагается, что Application и Module через Router добавляют обработку проходящих Message.

Tx

Обеспечивает захват и высвобождение транзакции к БД. Позволяет обратиться к инстансу транзакции и получить его по идентификатору. Позволяет реализовать pessimistic lock на уровне агрегатов.

Auth

Набор сервисов для авторизации и хранения бизнес-информации о пользователе.

Async Mailbox

Абстракция актора. Использование совместно с агрегатом позволяет реализовать эффективный pessimistic lock

Reactive

Circuit breaker

возвращает предопределенный ответ в случае непозволительно-длинной обработки. Им может быть и timeout.

Back-pressure

приостанавливает загрузку и продвижение сообщений в случае перегрузки системы