レイヤーアーキテクチャの見直し：MSDNブロガーの視点

ソフトウェア技術の複雑さについて、MSDNブロガー 萩原正義氏が語ります。現在のソフトウェアは「不必要に複雑」な部分がある。しかし、複雑さが生じるにはそれなりの理由があるのだ。初出は2007年4月。

[萩原正義（マイクロソフト），ITmedia]

（このコンテンツはMSDN Blog「The First Virtue」からの転載です。エントリーはこちら。なお、記事内容はすべて筆者の個人的な見解であり、筆者が勤務する企業の立場、戦略、意見等を代表するものではありません）

　現在のソフトウェア技術は不必要に複雑な部分があります。

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

　例えば、ファイナライザは非決定論的なVMのGC（ガベージコレクション）に依存する以上、リソースの消費に対して安全な見積もりができないという点では、あるべき機能ではありません。また、オブジェクトを生成するDI（依存性注入）と解放するGCは、対となる機能ですが、実現する場所もメカニズムも異なっています。これは不要な複雑さです。

　これ以外にも、.NETでのロールベースのセキュリティと、コードアクセスセキュリティの併用は、アンマネージドなレガシーコードが多い状況では、必ずしも有効な使い分けとはいえません。

　技術の複雑さという点では、アーキテクチャも同様です。

　現在のレイヤーアーキテクチャは、クライアント／サーバシステムの欠点を補うために登場しました。例えば、

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

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

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

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

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

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

　最適性では、処理の性能面、データの一貫性などデータアーキテクチャの面、要求変更への対応、テストとの親和性、プロジェクト管理のやりやすさ、資産としての管理しやすさ、再利用性の高さ、安定性などを考慮していかなければなりません。

　こうした面では、性能や可変性に対する多くのパラダイムの適用可能性、データアーキテクチャのプラクティス、開発基盤技術を総合的に考える必要があります。これらを別の機会に解説していこうと思っています。

　ただ、ここでは、ドメイン駆動設計の採用、関心の分離がなされており、変化する部分としない部分を分離すること、ロジックはできるだけpure（naked） objectとすること、といった原則を守っていく必要があります。