あなたが述べた問題を解決する私の一般的なアプローチは、Akkaコードから "ビジネスロジック"を分離することです。これによりビジネスコードをユニットテストすることができます&イベントは非常にリーンなAkkaコードを書くことができるAkkaから独立してテストされています。
例として、あなたはビジネスロジックは、いくつかのData
を処理することですねと言う:
object BusinessLogic {
type Data = ???
type Result = ???
def processData(data : Data) : Result = ???
}
これは、任意の同時実行環境で実行することができますきれいな実装であるだけではなく、アッカ(スカラ先物、Javaスレッド、...)。このビジネスロジックは、個別イベントシミュレーションで実行することができます。
val someDate : Date = ???
val historicData : Iterable[Data] = querySomeDatabase(someDate)
//discrete event simulation
val historicResults = historicData map BusinessLogic.processData
同時にロジックをAkka Actorsに組み込むことができます。一般的には、「データディスパッチャー」よりごreceive
方法の何をしないために非常に有用である、receive
に存在する任意の実質的なコードがあってはならない。
class BusinessActor extends Actor {
override def receive = {
case data : Data => sender ! BusinessLogic.processData(data)
}
}
私はちょうどここに同様の議論に出くわします。http: //stackoverflow.com/questions/13550532/time-based-simulation-withactors-model – user6296589
私自身のExecutionContextを実装し、カスタムakka.Schedulerを提供するかもしれません。それで十分ですか? – user6296589