レイヤー化の原則

ここ数日、私はジミー・ニルソン氏が主催するノルウェーでのエンタープライズソフトウェアに関するワークショップに参加していました。ワークショップ中、いくつかの設計原則を考案し、投票するセッションがありました。

ルールは次のとおりです。全員が優れたレイヤー化のための原則を提案でき、リストに追加されました。原則に関する議論はほとんど行われず、必要に応じて明確化のみが行われました。人々は気に入った原則でもそうでない原則でも提案できました。ルールは、現場で耳にした原則をキャプチャすることでした。

リストができたら、投票の時間です。全員が10の賛成票と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
• レイヤー境界で例外を再スローする。0/15
• レイヤーは独立して保守およびバージョン管理されるべきである。2/0
• レイヤーは別々のデプロイメントユニットを持つべきである（例：各レイヤーの別々のjarまたはアセンブリ）。0/7
• レイヤーはインフラストラクチャの側面（例：セキュリティ）を共有してもよい。7/0
• ドメインレイヤーは外部システムと通信すべきではない。サービスレイヤーがそれを行うべきである。2/3
• インバウンド外部インターフェースモジュール（例：Webサービスハンドラー）にはビジネスロジックを含めるべきではない。10/0

明らかに、このリストをあまり深く読み取ることはできません。良いグループの人々でしたが、エンタープライズ開発の専門知識の決定的な情報源ではありませんでした。原則もやや緩く表現されており、演習に1時間以上費やしていたら、整理されていたであろう重複や不正確さがあります。しかし、このリストが少し考えさせ、議論を促す可能性があると思います。

私は、驚いたことがあったかどうかを人々に尋ねました。何人かの人々は、頻繁に耳にしていた（そして嫌いだった）原則が投票で却下されたことに驚きました（レイヤーごとの開発チームの分離とレイヤー境界での例外の再スロー）。同様に、「ビジネスレイヤーは技術サービスの抽象化のみを使用する」ことが、実際にはめったに行われないにもかかわらず、非常に強い支持を得たことに驚きがありました。