Должен ли я вести реестр детей-актеров?

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

Сначала я пытаюсь задать более общий вопрос:

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

Я попытаюсь упростить проблему, с которой столкнулся: скажем, у меня есть акторная система, и есть актор с именем Backlog.

Бэклог отвечает за создание и контроль заданий (также исполнителей).

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

Ресурсы – это исполнители, не контролируемые в Невыполненной работе. Количество ресурсов ограничено.

С ресурсом в любой момент времени может быть связано только одно активное задание.

Возможно, что Ресурс не связан с Заданием. Возможно, что Ресурс не знает, что он связан с Заданием.

Ресурсы иногда обнаруживают датчики. Детектору необходимо знать Намерение Ресурса. Намерение является частью изменяемого состояния Задания.

Ресурс не имеет намерения сам по себе, только когда он связан с заданием, но он должен указывать намерение при запросе, поэтому необходимо убедиться, что есть связанная задание. (Поскольку детектор определяет Ресурсы, а не Задания.)

В моем дизайне ресурс должен запрашивать у Backlog задание, если его нет при обнаружении.

Теперь Backlog может содержать или не содержать Задание для этого ресурса. Если это не так, он должен создать его (допустим, он знает, как это сделать). Для этого ему необходимо знать, какие из его заданий активны и не связаны ли какие-либо из них с запрашиваемым ресурсом.

Все еще со мной?

Итак, как мне заставить Backlog узнать, есть ли в нем Job для Resource R? Должен ли я передать сообщение всем актерам задания и спросить их, активны ли они? А также если они случайно обрабатывают R? Как мне убедиться, что все Jobs действительно обработали его и сколько я должен ждать, пока они это сделают (тем более, что 0 мс кажется единственной приемлемой производительностью для таких простых задач).

Или мне следует сохранить словари, содержащие ссылки на исполнителей Job по идентификаторам Resource? А также (последние известные) государства, участвовавшие в этом решении? И тогда как мне поддерживать эти словари? Ищете события домена? Или ввести еще больше сообщений для Заданий, чтобы сообщать Бэклогу об изменениях их состояния с гарантией хотя бы один раз?

Честно говоря, мне нравится мышление и преимущества использования акторной модели, но огромное количество кода, необходимого здесь для реализации функциональности, похожей на одну строку запроса LINQ в традиционном объектно-ориентированном подходе, заставляет меня беспокоиться о том, насколько готовы остальные. команды будет обрабатывать этот код.

ОБЪЯВЛЕНИЕ

У меня есть участник Backlog, отвечающий за создание и контроль Jobs, других участников, которые представляют концепцию в предметной области. В некоторых случаях необходимо выбрать ровно одно из этих заданий на основе некоторых критериев, связанных с изменяемым состоянием дочерних акторов, или определить, нет ли в данный момент доступного задания. (Наличие нескольких подходящих заданий указывает на проблему и должна быть обнаружена.)

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


person tgz    schedule 11.01.2018    source источник


Ответы (1)


Несмотря на то, что вы описали многое, не хватает некоторых важных деталей, например, обрабатываются ли бэклоги по FIFO? это важно для решения.

  1. Например, если они это сделают, я бы использовал какую-то очередь, такую ​​​​как RabbitMQ, где актеры могут вытягивать задачи, когда они будут готовы, таким образом, актеру невыполненной работы не должно быть дела, он просто отправляет задание в соответствующую очередь.
  2. Если вас не волнует именно порядок, вы можете использовать маршрутизаторы и отправить запрос (команду/сообщение) одному из |R| исполнителей заданий и использовать, например, стратегию маршрутизации с наименьшим размером очереди.

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

Отношение к LINQ мне совсем не ясно, потому что вы описали, если в вашем вопросе что-то принципиально отсутствует.

person Yoav Kaplan    schedule 20.01.2018
comment
Спасибо, @Yoav. Попробую немного пояснить. Основная проблема здесь заключается в том, что когда Resource R сообщает бэклогу о назначении задания, бэклог должен знать, какой из них подходит, и выбрать ровно один. Если ни один не подходит, он должен создать новый. Пригодность работы не может быть определена по идентичности работы, она зависит от состояния, которое скрывают действующие лица. Мой текущий подход состоит в том, чтобы создать «опрос», транслируя критерии для каждого задания и ожидая, пока все они подтвердят ACK или NACK. - person tgz; 21.01.2018
comment
Что касается запроса LINQ, я просто имел в виду, что в традиционном ООП невыполненная работа будет просто набором заданий, и я выберу правильный, например jobs.Where(job.ResourceId == rId && job.State == JobState.Active).SingleOrDefault(). Поскольку актеры скрывают свое состояние, мне приходится делать гораздо больше работы, чем это. Я ценю преимущества актерской модели, я просто вижу, что МНОГО убеждает мою команду в ближайшем будущем, и это меня несколько беспокоит. :) - person tgz; 21.01.2018