レイヤーアーキテクチャの見直し

現在のソフトウェア技術は不必要に複雑な部分があります。
世の中の要求から、複雑にならざるを得ない部分もあるのですが、
技術的な発展の経緯や、かならずしも技術だけでは決まらない互換性、標準化、政治的決定などがあるからです。

たとえば、ファイナライザは非決定論的なVMのGCに依存する以上、リソースの消費に対して
安全な見積もりができないという点では、あるべき機能ではありません。
また、オブジェクトを生成するDI（依存性注入）と解放するGCは、対となる機能ですが、
実現する場所もメカニズムも異なっています。これは不要な複雑さです。
これ以外にも、.NETでのロールベースのセキュリティと、コードアクセスセキュリティの併用は、
アンマネージドなレガシーコードが多い状況では、必ずしも有効な使い分けとはいえません。

技術の複雑さという点では、アーキテクチャも同様です。
現在のレイヤーアーキテクチャは、クライアント/サーバシステムの欠点を補うために登場しました。たとえば、

• ロジックコードの共通化、集中化が可能。
• スケーラビリティを確保する。
• マルチチャネルに対応できる（MVC）。
• セキュリティを確保できる。
• 配布、集約など管理コスト面で有利。
• 移植性の対応。

での優位性からレイヤーアーキテクチャが主流となりました。

しかし、レイヤーアーキテクチャには、

• ユースケース（要求）の実現がレイヤーにまたがる。そのため、要求変更への対応、変更の局所化がむずかしい。
• 各種リソース（スレッド、コネクション）のプール、キャッシュなどが多段階になり、処理性能、管理などが複雑。
• エラー処理の責任箇所の特定。
• DTOの転送効率の問題と、プロセス外呼び出しの性能が悪い。
• 名前のルックアップのオーバーヘッドを伴う。
• 必ずしも再利用性の高い配置にはならない。

といった問題があります。

特にSOAを前提とした場合に最適なアーキテクチャではありません。
また、より動的なオブジェクト間の関係を支援する実行環境としても最適ではありません。

最適性では、処理の性能面、データの一貫性などデータアーキテクチャの面、要求変更への対応、テストとの親和性、プロジェクト管理のやりやすさ、資産としての管理しやすさ、再利用性の高さ、安定性などを考慮していかなければなりません。
こうした面では、性能や可変性に対する多くのパラダイムの適用可能性、データアーキテクチャのプラクティス、開発基盤技術を総合的に考える必要があります。これらを別の機会に解説していこうと思っています。
ただ、ここでは、ドメイン駆動設計（*）の採用、関心の分離がなされており、変化する部分としない部分を分離すること、ロジックはできるだけpure（naked） objectとすること、の原則を守っていく必要があります。

（*） ドメイン駆動設計とは、https://www.domaindrivendesign.org/