「ブレイクスルー」と「揺さぶり」

「エリック・エヴァンスのドメイン駆動設計」の第8章「ブレイクスルー」を読んで、「UMLモデリングの本質」で紹介されている「揺さぶり」との関連を感じたので、まとめてみます。

モデルのブレイクスルー

あるドメインのモデルとして、最初から最適なものを作成できるわけはありません。人によっては、プロジェクト初期のモデルから、ある程度柔軟な、良いモデルを作ることができるでしょう。しかしながら通常、そのドメインを表す、より本質的な、優れたモデルが存在します。ただ、モデルというのは、一度ある程度安定した状態に到達すると、動きをとめてしまい、なかなかそこから脱出しにくいものです。僕の中では、下図のようなイメージです。いわば、局所解に捕らわれてしまっている状態です。

f:id:GOLEM-XIV:20110421213222p:image

それをより大域的な解へ導くのが「リファクタリング」ではないでしょうか。ここでいうリファクタリングは、Fowlerの「リファクタリング」で紹介されている技術的なものというよりは、業務的な、ドメインの本質に関するものです。DDD本でも、「…リファクタリングの中でシステムの活力に最も影響するのは、ドメインについての新たな洞察によって動機づけられたものや、コードを通してモデルの表現を明確にするものなのだ。」というような記述があります。

つまり、そのようなリファクタリングによってモデルを変化させ、局所解から脱出するエネルギーを与えて到達するのが「ブレイクスルー」というイメージです。あるきっかけで局所解から抜け出せれば、一気に深いモデルに到達できる場合もあります。

f:id:GOLEM-XIV:20110421213223p:image

モデルの揺さぶり

第8章「ブレイクスルー」を読み、そのようなことを考えていたときに、「UMLモデリングの本質」に書かれていたことを思い出しました。この書籍でも、モデルを局所解にとどまらせないための方法が紹介されています。それがモデルの「揺さぶり」です。

揺さぶりとは、ビジネスモデリングを試したり、オブジェクト図を描いてみたり、アナリシス・パターンを適用してみたり、実装モデルを検討してみたり、とにかく色々な方法でモデルを検証してみて、モデルの柔軟性を高めるための方法です。書籍中では、揺さぶりによって、「後で起こりうる要求変更を想定してモデルを検証し、改良する」「重要な概念を取りこぼさないように」するとの記述があります。書籍でも、揺さぶりによって当初のモデルを、より深いモデルに進化させている例が2、3紹介されています。

f:id:GOLEM-XIV:20110421221352p:image

両者に共通するもの

使用されている用語に違いはあるものの、両者とも「モデルをいかに進化させるか」という観点では、同じ事を言っているのだと思います。つまり、

  • 一般的に、モデルはある程度安定した状態に留まろうとする性質を持つ。*1
  • よって、より深いモデルに到達するには、(リファクタリング、揺さぶりによって)「意識的」にモデルを進化させる取り組みを続けていかなければならない。

ということです。

これは個人的な実感にも合致します。技術的なもの、政治的なもの、その他様々な理由で、一度作成されたモデルはなかなか変更しづらいものです。しかしながら、そのまま変更せずにいて、上手くいったケースは少なかったというのが正直なところです。より良いモデルへ到達するために必要なのは、モデルについて真剣に考え抜き改善していくこと、そしてなにより、それを継続することなのだと思います。

*1:本来は、モデル自体が留まろうとしているのではなく、それに関わる人々がモデルの変化を躊躇する、というのが正しいのですが。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です