RDRA/ドメイン駆動設計(DDD)/ICONIXでDomainをEnableにしよう

ThoughtWorksアンソロジーに載っているエッセイに、「オブジェクト指向エクササイズ」があります。
これに書かれている「９つのルール」がとても興味深いものです。
これを実践するだけで、コード領域についてはかなりよくなるのではないか？という予感があります。
まず「９つのルール」を以下にあげてみましょう。

1. 1つのメソッドにつきインデントは1段階までにすること
2. else句を使用しないこと
3. すべてのプリミティブ型と文字列型をラップすること
4. 1行につきドットは1つまでにすること
5. 名前を省略しないこと
6. すべてのエンティティを小さくすること
7. 1つのクラスにつきインスタンス変数は2つまでにすること
8. ファーストクラスコレクションを使用すること
9. Getter、Setter、プロパティを使用しないこと

ざっと見てみると、センセーショナルに思う内容もあるのではないでしょうか？
では、まず1の「1つのメソッドにつきインデントは1段階までにすること」について書いてみましょう。

このルールの目的は、メソッドの仕事をシンプルにして、コード簡潔にすることです。

「インデントが一段階」ということは、制御構造（ループや分岐）が一つということです。
例えば、メソッドの中にforループがネストしているようなコードはNGです。
＃ThoughtWorksアンソロジーに載っているサンプルもそうですね。

そのようなコードをリファクタリング手法のメソッドの抽出等を使い、インデントが1段階になるまで抜き出します。
今時はEclipseなどのIDEが進歩しているので、このような作業もかなり簡単になりました。

リファクタリングの第一歩には、このルールの適用が最適な気がしますね。
このルールでまずはメソッドを抽出し、新たなクラスを発見し、メソッドを移動する。
これを繰り返していくだけで、クラスもメソッドも小さくなりコードの保守性があがりそうです。

アジャイルな開発プロセスで大事なのは、フィードバックすることです。
フィードバックする・されるということは、自分以外の何か（人や設計）とシンクロしながら進むということです。
XPで言うと、

• ペアプログラミングではナビゲーターとドライバーが一緒に考えて、コミュニケートしながらプログラミングをする
• オンサイト顧客とコミュニケートしながらストーリーカードを具体化する

なんていうことが該当します。とにかくコミュニケーションすることで、お互いにフィードバックしながら進むのがXPのスタイル。

XPに限らず、アジャイルな開発に共通して言えることは、工程の初めから全てを見通して進んでいるわけではないということ。
アジャイルなプロセスでは、途中でいろんなことを発見しながら進み、見つかったことをフィードバックしていきます。
私たちが今実行中のICONIXプロセスについても、同じことが言えますね。

ドメインモデリング→ユースケース→ロバストネス分析・・・と進んでいきますが、その途中でいろんなものが見つかります。

たとえば、

1. ユースケースを記述している最中にドメインモデルが見つかる。（見つかったら、ドメインモデルのダイアグラムに追加する。）
2. ユースケースを記述している最中に、要求が見つかる。（見つかったら、要求に書き足して、ユースケースに関連付けておく。）
3. ロバストネス分析をしている最中に、代替ケースが見つかる（見つかったら、ユースケース記述に書き足す）

といった具合です。

実は、ここでエンジニアがフィードバックを怠っても、コードは作成される場合もあります。
でも、「コードができればいいじゃん」的なノリで進むと、実は痛い目に会います。
たとえば、1.の場合にはドメインモデルが足りなくなる。
ドメインモデルは、互いの理解の共通語彙であるので、自分以外のエンジニアや顧客とのコミュニケーションに支障をきたす恐れがある。
また、せっかく発見したのにドメインモデルがないと、へんなクラスにメソッドを割り当ててしまうこともあるでしょう。

2.の場合には、顧客の理解が不足し、受入テストのケースが落ちてしまう可能性が高いです。
要件定義のフェーズでは、全ての要求は出ていないと思ったほうがまちがいないでしょう。
ユースケースを書いているときには、本当によく要求が見つかります。

3.の場合には、やはりコードから代替ケースが落ちる可能性があります。
コードはできたとしても、システムテストのケースからは落ちてしまいそうです。
ICONIXプロセスは、「設計する」ことをとても大事にしていると思います。コードだけではなく、テストも設計駆動なので、
設計へのフィードバックを怠ると、テストも不十分になってしまいます。

ICONIXプロセスに推奨ツールがあるのは、機能面もさることながら、フィードバックの容易性も考えてのことだと考えています。
設計リポジトリを共有し、ほぼ全てを設計できるツールを用いて、何かを見つけたらすぐにフィードバックする。
そういう良いクセを習慣づけて、速く、良いソフトウェアを作れるようになっていきたいものです。