アナリシスパターン - 非常にとっつきにくいが読めば読むほどに良さがわかる名著

アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)

Analysis Patterns: Reusable Object Models (Addison-Wesley Object Technology Series)

Java EEを含めて、業務システムの開発をオブジェクト指向で行う場合には是非勉強しておきたい名著です。翻訳は必ずしも悪いわけではないとは思うのですが、原文の微妙なニュアンスが伝え切れていないところがあり、できれば原書と読み比べながらじっくりと時間をかけて理解するのがベストと思います。日本語にしてしまうと、原書で感じられるプログラミングとのつながりがどうしても薄くなってしまうというところがあります。アナリシスパターンというと上流のモデリングに関する本で、プログラミングには一切関係がないように思っている人がいるかもしれませんが、もともと、Smalltalkのコード例が書かれていたり、3層レイヤーや参照・値オブジェクトなどの実装よりの視点が書かれていたりするように、ファウラーのプログラマーとしての経験がところどころに織り交ぜられているのを感じとることができます。その中に出てくる分析クラスもAccountとかContractなどと英語で記述されていると、自然にJavaなどのオブジェクト指向言語におけるクラス設計とのつながりを意識して読めるのですが、勘定とか契約などと翻訳してしまうとちょっと距離があるように感じられてしまいます。また、状態図中に描かれたcanBeExercisableなどのキャメルケースで書かれた条件は英語だとメソッドにスムーズに結びつくのですが、「行使可能か」などと翻訳されるとプログラムとは別物のように思えてしまいます。この本で常に重視されているのはクラスのインターフェースや責務、多態的な振る舞いということであり、一般に上流工程でよく行われるような純粋なデータモデリングの本では決してありません。この点、日本で上流と下流が分離されているというのはIT業界のゼネコン構造に加えて、言語の問題も大きいのではと思えてしまいます。Javaでもきれいにコードを設計するとかなりDSLというか英語的には上流の設計に近づけるのですが、日本人はJavaのコードを仕様書としてでなく記号の羅列と考えてしまう傾向があると思います。（最悪なケースだとUC1001とかPrg1503などの無意味なクラス名をつける規約を押し付けている場合さえあるみたいですが。）
あと、この本に出てくる分析モデルやパターンは、表面上特定の業務分野を題材として取り上げているのですが、そこに出てくるパターンは他の業務であっても汎用的に使えるアイデアになっているものが多いというところも見逃してしまいがちですが大切なポイントかと思います。たとえば、本書ではデリバティブ商品のストラドル*1の例を取り上げて、Productパターンというパターンが紹介されていますが、これは、顧客に対してひとつのProductとして組み合わされて取引される場合でも、裏のトレーダーにとってはプットとコールの別々のContractの集合としてばらばらに扱った方がよいという考え方です。この考え方は、FX取引のOCOやIF-DONEのような複合注文を扱う場合や、金融以外でも商品をセット販売するような場合には実際多くのシステムで幅広く応用できる考え方であると思います。このパターンを知らないと明細を独立したエンティティクラスとして抽出する発想に至ることがなかなか困難なのではと思います。
私も最初は本書の内容や本当のよさがなかなか理解できず、半端な理解のまま長いこと本棚に放置していたのですが、最近になって再度読み返してみると、あのシステムではこういう設計にしておけばよかったと反省される箇所が多くあり、あらためて本当によい本だと感心させられます。とくにJPAなどの技術によりPOJOを使ってO/Rマッピングが気軽に使えるようになった今こそ、再度読み直してみるべき価値のある本だと思います。上流から下流までユーザー（ドメイン専門家）やビジネスアナリシスト、プログラマーが共通のドメインモデルに従って会話できるようになるのが私の理想で、そういうことがいつかしたいのであえてJava EE開発などという泥臭い開発の世界で仕事を続けているのですが、今のところ、なかなかそういうファウラーのような仕事ができるチャンスは少ないですね。

*1:同一銘柄(instrument）に対して同額の売り（プット）と買い（コール）のオプションを同時に購入する取引