「再利用」といっても2種類あって混乱を招きがちです、というだけの感想エントリ。
空間的再利用とは「複数のプロジェクトに対して同時にライブラリやコンポーネントを再利用すること」を言います。あるプロジェクトで作られたモノを複数のプロジェクトに展開するものの含まれます。一般的な再利用は「空間的再利用」を示す場合が多いと思います。
時間的再利用とは「そのプロジェクトにおいて同じライブラリやコンポーネントが使い続けられる」ことを言います。プラットフォームやアーキテクチャ、あるいは関係する他モジュールに変更があっても、昔のライブラリがそのまま（あるいは微妙な変更で）使えるという意味です。
再利用におけるメリット、例えばコスト削減効果は同じです。ですが、この2つの再利用は分けて考えた方が良い。簡単にいえば空間的再利用は「早く作る」ための再利用で、時間的再利用は「長く使う」ための再利用です。とはいえ、これについては異論があると思います。僕自身も整理中なので、ぜひ意見をください。
空間的再利用性を高めるにはドメインコンテキストからの独立性が重要になります。クレジットカードのオーソリは世の中で共有されているルールなので個別ドメインの事情からは独立します。そのため使い回しが可能です。あるいは特定のドメイン（ある業界／あるグループ）に特化し、その下のサブドメイン（ある企業）に適用することもよいでしょう。
ただし、コンテキストの独立性が維持されない場合は再利用はうまくいきません。一般的にビジネスロジックの再利用性を確保することは非常に難しいのは、同じ企業は2つないという単純な理由です。
一報で時間的再利用性が高めるためにはやや異なる視点が必要になると思われます。
例えばSalesforce.comでは自動アップグレードが提供されており、新しい機能が追加された場合でも、古い機能を利用するスクリプトやコードの実行は保証されます。これは時間的再利用性が高い状態と言えます。
内部的な仕掛けはシンプルで、スクリプトの実行エンジンを世代別に管理しており、実行時に切り替えているだけです。この方法が永遠に有効とは言いませんが、Apexは既にバージョン18になっており、これまで問題なく動作しているのは評価に値するでしょう。
同じような事例としてはEclipseを上げることができます。急成長をし続けていますが、過去のサードパーティ製プラグインがかなりの確率で動くのはすばらしいと思います（動かないのも、ちょっと直せば動くとか）。
過去、EJBなどの言われていた「コンポーネントの再利用」は空間的なものを指していました。これがうまくいくためにはコンテキストの固定が必要であり、実際、そのようにしたものは成功したと思っています（サントリーグループ内とか、一部の業界団体主導で行なわれた標準化）。
現在では時間的再利用性のほうが興味を集めていると思います。他人のコンポーネントを使って早く作るよりも、自分なりのコンポーネントを長く使いたい。ユーザーニーズの変化から再利用に対する捉え方も変わってきていると感じます。
