読者です 読者をやめる 読者になる 読者になる

はじめての #java_ja

ちょっと遅くなってしまいましたが、先日java-ja.dddという勉強会に参加させていただいたので、その振り返りを書いておきます。 僕にとってははじめてのjava-ja参加です。

第一部 ざっくり DDD 入門!!

はじめは エリック・エヴァンスのドメイン駆動設計の訳者である和智さんより、ドメイン駆動設計とは何ぞや?というお話がありました。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

入門編と銘打つだけあって、DDDのエッセンスが凝縮されたよいお話でした。僕はエリック・エヴァンスのDDD本をある程度読んで臨んだのですが、そうでない人にも非常にわかりやすかったと思います。

トランザクションスクリプト(手続き型)だと重要な業務ロジックが埋もれる

ドメインモデルと比較対象とされるのにトランザクションスクリプトがあります。これはビジネスロジックを一連の処理のまとまり(トランザクション)として定義し、それをプレゼンテーション層から直接あるいは薄いラッパーを介して実行する方法です。 この方法は1つのビジネスロジックがそれ専用の1つのトランザクションになるため、設計・実装がしやすいですが、そのトランザクションにはインフラストラクチャコード(永続化層とのデータのやりとり等)も含まれてしまうため、ビジネスロジックが埋もれてしまいがちだと言われています。

エリック・エヴァンスのDDD本では、この例として貨物船の予約システムの例が挙げられています。

// 貨物を追加する
int 予約済み貨物量 = …
if (予約済み貨物量 + 貨物.サイズ > 航海.積載量 * 1.1) {
    // 予約できない
    …
}

これは貨物船に載せる荷物はキャンセルを考慮して最大積載量の1割オーバーまで予約を受け付けるというシステムの一部です。 この箇所だけ見れば非常にシンプルなコードに見えるかも知れませんが、この前後にDBとデータのやりとりをするためのコードや画面表示を行うためにデータを整形するためのコードがあると、「最大積載量の1割増まで予約を許可する」という重要な仕様がインフラストラクチャコードに埋もれてしまいます。 通常はこれを仕様書や設計書といわれるものに記述するわけですが、それは膨大な量のドキュメントのうちのごく一部のため、見落としやすいです。

これをドメイン駆動で設計すると、仕様(Specification)パターンやストラテジー(Strategy)パターンとして実現されます。 以下は仕様パターンの例です。

class 予約可能貨物仕様 implements 仕様インターフェース
{
    private int 予約済み貨物量 = …

    予約可能貨物仕様(予約済み貨物量)
    {
        this.予約済み貨物量 = 予約済み貨物量;
    }

    isSatisfiedBy(貨物)
    {
        return 予約済み貨物量 + 貨物.サイズ <= 航海.積載量 * 1.1
    }
}

このようにすることで、ビジネスロジックを閉じ込めることができ、変更にも強い堅牢なアプリケーションを実装可能になります。

和智さんにサインもらった

エリック・エヴァンスのDDD本は今の僕にとってはバイブルみたいなもの*1なので普段から結構持ち歩いているんですが、なんと訳者である和智さんにサインお願いしたところ快くいただけました! 和智さん、ありがとうございます!!!

f:id:a_suenami:20130327001830j:plain

第二部 ガッツリ DDD 実践編!!

第二部として増田さんから実践編ということでお話しいただきました。

こちらは実践編ということで具体的なクラス設計のしかたや心得みたいなものでした。タイトルの通り、「プログラミングとは名前探しである」というのがキーメッセージだったのですが、その意味はよくあるような変数名やメソッド名、クラス名にこだわりましょうというようなものでなく、もっと深いこだわりを感じました。 業務で使う言葉はそれぞれがすべてオブジェクトとして表現されるべきで、その結果、システムは業務の言葉で埋め尽くされるはずだという言葉に感銘を受けました。

業務を理解するためには1日書けてでもその分野について調べる

これぞまさしくDDDだという感じですが、業務を正しく理解し、その分野の語彙を増やすことは非常に価値があることなので、そのためなら丸1日潰してでもその分野の文献等を読み込むべきだとおっしゃってました。 特にクラス名やメソッド名は通常英語で命名するので、英語で書かれた入門書が適切なようです。

メソッドは3行以内!ユニットテストは書かない!

この言葉にはさすがに会場がざわついていましたw 業務で使われる言葉をひとつひとつオブジェクトにして、徹底的に責務を限定していけばひとつのメソッドがそんなに肥大化することはないということなのでしょうか…

ひとつのクラスがそんなに複雑になることはないので、ユニットテストもほとんど書かないそうな。ユニットテストっぽいものはあるみたいですが、それはミニシナリオテストのようなものだとのことです。

汎用部品より専門部品!再利用は考えない!

個人的に一番感銘を受けた言葉は「そのドメインにとって価値の源泉であるはずのでビジネスロジックが再利用可能なはずがない」です。

我々プログラマは汎用化・抽象化を無条件に善だと考えがちですが、確かにビジネスアプリケーションだとこういう考え方もあるかと。とにかく徹底的に業務に特化していくようにとのことでした。

第三部 俺にもちょっと DDD 喋らせろ!!

@j5ik2o さんと @t_wada さんからLT*2がありました。

某動画配信サービスのAndoroidアプリのサーバー構築にドメイン駆動を実践したという話だったり、SQLアンチパターンのひとつである「マジックビーンズ(魔法の豆)」はまさにDDDそのものだよねという話が聞けたり非常に勉強になりました。

java-ja 怖い

最後に。 スタッフの方々は「java-ja怖いとかブログに書かないでねーw」とおっしゃってましたが、これは振りだろうと思うので一応書いておきますw

今回僕ははじめてjava-jaに参加させていただいた*3のですが、最近参加している他の勉強会とはずいぶん雰囲気が違うなぁと感じました。 良くも悪くも賑やかというか笑いとツッコミが絶えない感じで、 他のコミュニティと違って怖かった 他のコミュニティと違えどこれはこれでいいコミュニティだなぁ、と。

Java自体すっかり最近はご無沙汰なんですが、また機会があればぜひ参加させていただきたいと思います。

*1:ちょうど今ドメイン駆動設計にハマっています

*2:Long Talkの略ですw

*3:というか、そもそもJavaをもう長らく書いていない