構造化分析・プログラミング

「良くない設計」や「良くない実装」をしてしまわないための一番の近道は、「構造化分析手法」の適用だと考えています。基本的に規模が大きければ大きいほど、携わる人間が多ければ多いほど、そして仕様変更が入る確率が高ければ高いほど、構造化分析および構造化プログラミングがなされていないと手詰まりになります。

私は、はっきりいって構造化プログラミングは、好きではないし、有害とさえ思っています。なぜなら、トップダウンでメソッドを詳細化していく方法は、より抽象度の高いメソッドがより具体的なメソッドに依存することになり、変更が入ったときにその影響を受けやすくなってしまうためです。
オープンクローズの原則は、最も守らなければいけない重要な原則です。仕様の変更はコードを修正するのではなく、コード追加で対応できなければならないのです。
OCPを守るために、くーすでどうしているかというとロジック(メソッド)は常にインターフェース経由で呼び出すようにします。あるロジックが別のロジックを呼び出す必要があった場合、DIコンテナによってロジックオブジェクトをDIしてもらい、それを利用するのです。
ロジックごとにインターフェースを用意します。ただし、ここでいっているロジックは、ユーザから見てレビューできないようなものは含まれません。
仕様に変更が起きた場合には、そのロジックオブジェクトのインターフェースを新しい仕様で実装しなおし、それをDIしてもらえばいいのです。
仕様変更によって利用する側が影響を受けることはありません(もちろんインターフェースが変わらない範囲でですが)。
業務ロジックを分析するのに構造化分析を使うのは、望ましいことだと思っています。なぜなら、私たちが業務をこなすとき、一定の手続きに基づいているはずで、それは構造化されているはずだからです。
くーすの最も根本的な考えは、現実により近いモデルが良いモデルだということです。そうすると、仕様変更が起きたときも、どこを修正すればいいのかが明確で、仕様変更に見合う分の修正をすればよいからです。
私たちが行う業務というのは、伝票などの紙と業務手順(マニュアル)で成り立ってますから、それをそのままモデルに落とすのが良いでしょということです。
ちなみにドメインモデルだと特定のメソッドだけ仕様変更したいなんてのはOCPを守って行うのは難しくなります。全メソッドをStrategyパターンで切り替えられるようにするのは現実的でないしね。