Как мне лучше всего разделить поведение между актерами Akka?

Есть действительно куча способов, которыми вы можете это сделать. Я перечислю два способа OO (аналогично тому, что предлагает @Randal Schulz) и еще один функциональный способ. Для первого возможного решения вы можете сделать что-то простое:

case class MessageA(s:String)
case class MessageB(i:Int)
case class MessageC(d:Double)

trait MyActor extends Actor{

  def receive = {
    case a:MessageA =>
      handleMessageA(a)

    case b:MessageB =>
      handleMessageB(b)

    case c:MessageC =>
      handleMessageC(c)
  }

  def handleMessageA(a:MessageA)

  def handleMessageB(b:MessageB) = {
    //do handling here
  }

  def handleMessageC(c:MessageC)
}

class MyActor1 extends MyActor{
  def handleMessageA(a:MessageA) = {}
  def handleMessageC(c:MessageC) = {}
}

class MyActor2 extends MyActor{
  def handleMessageA(a:MessageA) = {}
  def handleMessageC(c:MessageC) = {}
}

При таком подходе вы определяете в основном импл абстрактного актора, где функция receive определена для всех обрабатываемых сообщений. Сообщения делегируются defs, где должна быть реальная бизнес-логика. Два из них являются абстрактными, позволяя конкретным классам определять обработку, а один полностью реализован для случая, когда логика не должна отличаться.

Теперь вариант этого подхода с использованием шаблона стратегии:

trait MessageHandlingStrategy{
  def handleMessageA(a:MessageA)

  def handleMessageB(b:MessageB) = {
    //do handling here
  }

  def handleMessageC(c:MessageC)
}

class Strategy1 extends MessageHandlingStrategy{
  def handleMessageA(a:MessageA) = {}
  def handleMessageC(c:MessageC) = {}  
}

class Strategy2 extends MessageHandlingStrategy{
  def handleMessageA(a:MessageA) = {}
  def handleMessageC(c:MessageC) = {}  
}

class MyActor(strategy:MessageHandlingStrategy) extends Actor{

  def receive = {
    case a:MessageA => 
      strategy.handleMessageA(a)

    case b:MessageB =>
      strategy.handleMessageB(b)

    case c:MessageC =>
      strategy.handleMessageC(c)
  }
}

Здесь подход заключается в передаче класса стратегии во время построения, который определяет обработку для a и c, при этом b снова обрабатывается одинаково независимо. Эти два подхода очень похожи и достигают одной и той же цели. Последний подход использует частичную цепочку функций и может выглядеть так:

trait MessageAHandling{
  self: Actor =>
  def handleA1:Receive = {
    case a:MessageA => //handle way 1
  }
  def handleA2:Receive = {
    case a:MessageA => //handle way 2
  }  
}

trait MessageBHandling{
  self: Actor =>
  def handleB:Receive = {
    case b:MessageB => //handle b
  }  
}

trait MessageCHandling{
  self: Actor =>
  def handleC1:Receive = {
    case c:MessageC => //handle way 1
  }
  def handleC2:Receive = {
    case c:MessageC => //handle way 2
  }  
}

class MyActor1 extends Actor with MessageAHandling with MessageBHandling with MessageCHandling{
  def receive = handleA1 orElse handleB orElse handleC1
}

class MyActor2 extends Actor with MessageAHandling with MessageBHandling with MessageCHandling{
  def receive = handleA2 orElse handleB orElse handleC2
}

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

Вероятно, есть много других способов сделать то, что вы ищете, но я просто решил предложить вам несколько вариантов. Надеюсь, поможет.

До сих пор у меня не было причин сожалеть о том, что я переместил столько фактической функциональности моих сервисов (так называемая «бизнес-логика») в более низкий уровень, «обычную» и синхронную (а иногда и блокирующую) библиотеку, которая может быть протестирована. без усложнения актеров. Единственное, что я помещаю в классы Актеров, — это общее, долгосрочное изменяемое состояние, на которое действует этот обычный библиотечный код. Это, конечно же, а также логика декодирования и отправки сообщений функции Akka Actor receive.

Если вы сделаете это, обмен логикой в ​​том направлении, в котором вы ищете, будет тривиальным.