DDD連載記事
* なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか
* ドメイン駆動設計の定義についてEric Evansはなんと言っているのか
* モデルでドメイン知識を表現するとは何か
* ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か
* ドメイン駆動 + オニオンアーキテクチャ概略
はじめに
設計の善し悪しについて日々色々と議論することはあると思いますが、「良い設計」「悪い設計」について明文化した定義はあるでしょうか。各々の頭の中にぼんやりと、もしくは断片的にはあるものの、チームで良し悪しについて定義まですることはあまり多くないのではないでしょうか。
各プロジェクトで議論することには価値があると思いますが、一つ基準になるものがあると議論しやすいと思います。そこで一つ、オブジェクト指向の原則を提唱したUncle BobことRobert Cecil Martinが提唱している「悪い設計」の定義について参照してみましょう。
Uncle Bobについて
そのまえに、Uncle Bobについて紹介します。
Robert Cecil Martin(wikipedia)
有名な「クリーンコード」の著者、と言えばわかりやすいでしょう。そのほかにも、オブジェクト指向の設計原則であるSOLID原則の提唱者であったり、アジャイルソフトウェア開発宣言の共著者であったりと、ソフトウェア業界に与えた影響は計り知れない方ですね。
(余談ですが、ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何かで紹介したアプリケーションアーキテクチャ「クリーンアーキテクチャ」の提唱者もこの方です。運営されているサイトもClean Coderという名前で、クリーンという名称にはこだわりがあるみたいですね。クリーンアーキテクチャの"クリーン"ってどこから来たのか？と思ったらここからだったようです。納得。)
原典
今回の参照する原典は、古いUncleBobのサイトのThe Principles of OODのページのさらに中、The Dependency Inversion Principleの記事の中で紹介されていたものです。こちらの内容を引用・要約したものになります。
「悪い設計」とは
すべてのエンジニアが合意できると思われる、以下のような3つの性質を持つ設計を「悪い設計」と言っています。
- Rigidity :
It is hard to change because every change affects too many other parts of the system.- Fragility:
When you make a change, unexpected parts of the system break.- Immobility:
It is hard to reuse in another application because it cannot be disentangled from the current application.
和訳し、その後に記述があった詳細について一部意訳、要約を記述します。
1. Rigidity(硬さ)：
一つ一つ変更がシステムの他の多くの部分に影響を与えるため、変更するのが難しい。
一つの変更のために、依存モジュールに連鎖的に修正を加えないといけないことが原因となります。
修正を加える必要が有る範囲を設計者が予測できない場合、その影響やコストが予測できなくなります。そうすると、権限者は変更の承認を嫌い、変更に硬直的な圧力が働きます。
対策「依存するモジュールを少なくすること」、「依存するモジュールが論理的に推測できる範囲にすること」と言ったことが考えられるでしょう。
対照的な性質は、Flexibility(柔軟性)です。
2. Fragility(脆さ)：
変更を加えると、システムの予期しない部分が壊れる。
しばしば、変更時に概念的に関係がない領域にて新しい問題を生じさせることがあります。これにより、保守チームの信頼性の低下を引き起こします。開発を続けるほど、無関係に見えるところでの障害発生が発生し、その修正をするたびにまた別の障害が発生し・・・と、メンテナンスに掛かる工数が継続的にかかりづつけてしまいます。
対策は「概念的に関連があるモジュールのみに依存するようにすること」、1と同じく「依存するモジュールが論理的に推測できる範囲にすること」と言ったことが考えられるでしょう。
対照的な性質は、Robustness(堅牢性)です。
3. Immobility(移植性のなさ)：
現在のアプリケーションとの結合が強く、別のアプリケーションでの再利用が難しい。
実装の一部が業務的に固有なものに大きく依存する場合、その実装の再利用性は低くなります。設計者が実装の再利用について調べると、モジュールの分離、再利用のために必要な作業が非常に多いことが判明し、多くの場合は再利用することを諦めます。
対策は「モジュールの凝集度を高めること」でしょうか。
対照的な性質は、Reusability(再利用容易性)です。
まとめ
いかがでしょうか。「良い設計の定義」よりも、意外と「悪い設計の定義、の裏返し」で考えたほうがイメージがしやすいこともあるのではないでしょうか。
また、これを元に自分自身の考えや、チームの方針を再検討する土台としても使えるかもしれませんね。