http://martinfowler.com/bliki/LayeringPrinciples.html

ここ数日、ノルウェーで開かれたエンタープライズソフトウェアのワークショップに参加してきました。Jimmy Nilssonが主催するワークショップです。 そのなかで、いくつかの設計原則を挙げ、それに投票するというセッションを行いました。

ルールはこうです。 まず、レイヤリングに関する原則をみんなでリストアップしていきます。 次に、簡単なディスカッションを行います（各項目を明確にします）。 自分が好きだろうが嫌いだろが関係なく、 とにかく現場で聞いたことのある原則を残らず挙げていくのが、ここでのルールです。

リストができあがると、投票の時間です。 我々はドット投票の変形を使いました。 各自が賛成票と反対票をそれぞれ10票ずつ持つというものです。

以下に投票結果を掲載しました。 原則の後ろにある数字はそれぞれ、賛成票/反対票の数となっています。

  • レイヤ間の低結合度。レイヤ内の高凝集性。10/0
  • 関心の分離。11/0
  • レイヤは利用者を不可知でなければならない（レイヤはトップに何があるか知っていてはいけない）。4/4
  • 順応性：変更を容易にするため。2/0
  • ユーザーインターフェースのモジュールはビジネスロジックを含んではならない。10/0
  • ビジネスロジックレイヤにはユーザーインターフェースを含んだり、ユーザーインターフェースのモジュールを参照してはならない。8/0
  • レイヤ間で循環参照をしてはならない。8/0
  • 少なくとも3つのレイヤがある：プレゼンテーションレイヤ、ドメインレイヤ、データソースレイヤ。3/9
  • ビジネスレイヤは抽象的なテクノロジサービスのみ利用する。14/0
  • レイヤごとに開発チームを分ける。1/22
  • レイヤは単独でテスト可能でなければならない。12/0
  • レイヤは隣接したレイヤとのみやり取りをしたほうがよい。4/4
  • 下位のレイヤを上位のレイヤに晒さないように気をつけなければならない。1/0
  • 下位のレイヤを上位のレイヤから隠さなければならない。
  • レイヤは隣接したレイヤとのみやり取りをしなければならない。2/3
  • 下位のレイヤのインターフェースを変えることで、上位のレイヤのインターフェースを変えてはならない。2/5
  • レイヤの境界でディストリビュートする。0/18
  • レイヤは論理的なものであって、レイヤ間のディストリビューションを意味する者ではない。11/0
  • 下位のレイヤは上位のレイヤに依存してはならない。6/0
  • すべてのレイヤは秘密を持つべきである。3/2
  • レイヤは内部に対してシャイでなければならない。8/0
  • レイヤは代替可能でなければならない。2/0
  • レイヤは複数の上位レイヤを持ちうる。2/1
  • 常にドメインロジックをサービスレイヤで覆わなければならない。4/5
  • レイヤ境界で例外を再度throwする。0/15
  • レイヤは単独で保守、バージョン管理されなければならない。2/0
  • レイヤはそれぞれがデプロイメントユニットを持っていなければならない（例えば、各レイヤにjarファイルやアセンブリを用意）0/7
  • レイヤはインフラ要因を共有する（セキュリティなど）。7/0
  • ドメインレイヤは外部システムとやり取りしてはならない。代わりにサービスレイヤが行う。2/3
  • 外部インターフェースモジュール（Webサービスハンドラなど）は、ビジネスロジックを含んではならない。10/0

このリストから何かを得ることはできません。 すばらしいグループによる投票結果ですが、 エンタープライズソフトウェア開発における決定的な情報ソースとはなり得ないでしょう。 これらの原則は漠然と表されており、 重複した部分や不正確な部分があります。 それらを整理するには数時間かけて吟味することになるでしょう。

私はみんなに「驚いたものがあったか」と尋ねました。 すると、よく聞かれる原則（それから嫌われている原則）が投票によって落とされたことに驚いているひとが何人かいました （「レイヤごとに開発チームを分ける」や「レイヤ境界で例外を再度throwする」など）。 同様に、 「ビジネスレイヤは抽象的なテクノロジサービスのみ利用する」という 実際にはそれほど行われてないものがこんなに得票するとは、 という驚きの声も上がりました。

comment

*まさよしくんさんの日記

ファウラー氏のブログに興味深い結果があります。

低カップリングと高凝集、関心の分離、非循環参照の回避、独立テスト可能性、UIとロジックの分離、実装隠蔽などの原則に従うことが書かれています。原則論ですから、これ以上の詳細はわかりません。しかし、関心の分離をどうするかは大問題ですし、独立テストをやるためにはモックをどうするかなどの問題があります。同じThoughtWorks社のGregor氏はアジャイルEAIでこの問題のヒントを与えています。そして、UIとロジックの分離は状況に応じて分離しなくてよいアプローチもありだと思いますし、非循環参照はモデルを間接的に入れることで解決できますが、現実的には必要悪として使う場合もあります。

一方、してはいけない原則としては、階層を単位としてチームモデル、階層を単位とした配布、階層の境界をまたぐ例外の伝播などです。チームモデルについては意外性もあると書かれていますが、ファウラー氏自身のコメントや意見はありません。きっと彼の性格では、原則論と実践を分けて考え、適切に使いわければいいと考えているのでしょう。