想定している粒度が大きいのでは、と思った理由のひとつでもあり、かつモヤったのは、実装クラスは極力不可視にしておくべき、というくだり。DI や main のような汚れ役にインスタンス生成を押し付けるわけだけど、そいつらが同一パッケージにいるわけなかろう。具象クラスを隠してインターフェースだけを（循環参照せずに）露出させるには、jar のようなモジュールに閉じ込めるしかない…はず。なんかできそうな風に書いてあったけど。

アクターはそれぞれ異なる理由で変更を要求するので、別のアクターの要求とコンフリクトしないように境界を引いておけ、という指針にはなるほど。

少なくとも自分は、社内のロールモデルを追いかけていれば将来安泰だとか一瞬も思ったことがない

テストコードのヘルパーは多用しないほうがいい派。他のケースに適用できなくてむしろ複雑化したり、実装読まないと何をしてるかが分からなくなったりする。

Goなんかは言語レベルで結果とエラーの両方を返すようになってるので、このスタイルを支持する人たちがいるのは分かる。でも、そうでないことで困ったことはまだない。

あと、純粋関数であるために例外スローを避ける必要もないのでは…。結果とエラーはどちらか一方しか存在しえないのだから、戻り値に両方が含まれうるメソッドシグネチャは単にややこしいし、エラーハンドリングを強制できるわけでもない。

戻り値はアクションを表すオブジェクトにしましょう、という方針もあまり筋がいいとは思えない。実装時点で想定したアクションに抽象化できない変更要求が生じることは良くあるため。そのとき余裕がないと、戻り値のクラスに無理やり押し込めて複数の責務を内包させてしまったり、もっと悪いと副作用を書いてしまいがち。

逆にこれはAppルーターの機運！？とか一瞬思ったけど無駄な努力はよしておこう…