Как использовать участников для доступа к базе данных и DDD?

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

Одним из решений может быть завернутый DAO в безгосударственном акторе. Например, для каждой таблицы (или типа объекта домена или типа агрегата) в базе данных можно создать актера, который отвечает за все операции CRUD. Вариантом этого может быть разделение команд и запросов. Например, для каждого типа данных 1 командный актер (для concurrency) и 10 субъектов запроса (для parallelism).

Другой подход может заключаться в создании агентов с состоянием, представляющих ровно одну строку (или экземпляр объекта домена или совокупный экземпляр) в базе данных. Разумеется, база данных может быть в этом случае также хранилищем событий (например, модулем сохранения akka), и в конечном итоге последовательная проекция на базу данных, хранилище документов или кеш. Это не актуально. Этот подход на самом деле представляет собой реализацию кэша в памяти со всеми преимуществами и проблемами. Должна существовать стратегия уничтожения актеров, чтобы не хватать памяти через некоторое время.

Скажем, я хочу разработать приложение DDD с актерами Akka. Давайте сконцентрироваться здесь на командной части. По-моему, это должно быть реализовано таким образом: для каждого ограниченного контекста будет действовать порт-актер, например. Spray REST API, который направляет сообщения соответствующему участнику службы домена. Этот сервисный агент координирует бизнес-задачу с одним или несколькими агрегатами модели домена. Каждый отдельный агрегат является субъектом с сохранением состояния, который восстанавливается (или создается на новых данных) агентом службы из базы данных. Сервисный агент отправляет/передает сообщения всем участвующим агрегированным участникам. Актеры принимающей доменной модели будут выполнять проверку бизнеса на своем сообщении состояния +, а затем записывают свои изменения в базу данных, например. Slick DAO. После отправки done обратно в сервис-актер они будут остановлены. Когда все агрегатные участники закончены, сообщение done отправляется обратно отправителю сообщения. Вариант может заключаться в том, чтобы немедленно остановить участников модели состояния домена, но через промежуток времени, скажем, 3 минуты.

Является ли это допустимым шаблоном использования для DDD с помощью Akka?

Ответы

Ответ 1

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

Что касается операций обновления (CrUD), их можно разделить на непересекающиеся домены/осколки. Например, все операции с одной учетной записью должны быть предпочтительно обработаны одним актором. Можно иметь N практически независимых обработчиков и маршрутизатор, который маршрутизирует команды одному из них на основе account.hashCode% N, например. Таким образом, операции будут распределяться между участниками более или менее равномерно, и каждая учетная запись будет обрабатываться последовательно.

P.S. Slick, по-видимому, является библиотекой спуска db для приложений Akka.