業務ロジックの設計手法

くーすにおける業務ロジックの設計方法は、実はこれまでほとんど書いてなかったんですね。
心より恥じる(ふるっ)
そのため、TransactionScriptだとか構造化手法だとかという誤解が生まれたのでしょう。
くーすにおける業務ロジックの設計手法は、振る舞いのモデリングに焦点を当てたものです。
振る舞いのモデリングっていってもやり方は簡単。

1. あるコンポーネントは自分で処理するか、自分よりも詳細なことを知っている別のコンポーネントに処理を任せる。
2. 1を再帰的に繰り返す。

これだけです。このやりかただと、どんなに業務ロジックが複雑になっても、役割に応じた登場人物を増やすだけで済むので、個々のコンポーネントは、シンプルなままでいられるのです。
DIContainerのない時代には、登場人物が増えると、それを管理するコストもばかにできないものになります。徹底的に役割に応じてクラスを分割するという手法が現実的になったのは、やはりDIContainerが出てきたおかげだと思います。
それでは、いまはやり(?)の従業員の給与を計算するという業務ロジックを考えてみましょう。
まず最初のスタートポイントは、給与計算Logic.calculatePay(Employee)です。
給与を計算するロジック(給与計算Strategy)は、従業員のさまざまなファクターによって、変わることが予想されます。そんな細かいことを給与計算Logicコンポーネントは、知りたくないので、さまざなな給与の計算方法の求め方を知っている給与計算StrategyFactoryコンポーネントから給与計算Strategyを取得し、給与計算Strategyに処理を委譲します。給与計算StrategyFactoryは、DIContainerによって設定されていることとします。

給与計算StrategyFactory factory;
calculatePay(Employee employee) {

  給与計算Strategy strategy = factory.getStrategy(employee);

  return strategy.calculatePay(employee);

}

給与計算Strategyは、職務ごとに作成されるかもしれません。あるいは、扶養家族も加味するかもしれません。給与計算StrategyFactoryは、自分よりもさらに詳しい知識を持っているコンポーネントに必要なら処理を依頼すれば良いのです。
給与計算Strategy、給与計算StrategyFactoryともインターフェースになります。実装のことなど気にする必要はありません。給与計算のロジックが複雑になろうが仕様が変わろうが、給与計算Logicを利用する側には影響がありません。ロジックが複雑になっても登場人物が増えるだけで、個々のコンポーネントはシンプルなままです。
これが、くーすにおける振る舞いのモデリングなのです。