DevLoveのBeautiful Development（DDD勉強会）に参加してきました

書籍紹介 分析・設計技法 DDD 勉強会・セミナー

昨日、DevLoveの主催するBeautiful Development（ソフトウェアの核心にある複雑さに立ち向かう）という勉強会に参加してきました。
https://sites.google.com/a/devlove.org/development/past-beneficiaries/devlove_ddd2
今回は、Domain-Driven Design（DDD）をテーマにした勉強会でした。ここで簡単にレポートさせていただきたいと思います。

勉強会参加のすすめ

実は、DevLoveの勉強会に参加するのはまだ今回が2回目です。*1
このように私自身もまだDevLove初心者なのですが、今回は初参加の人がかなり大勢いたようです。*2こういった技術者の勉強会というと、初心者お断りというか、相当の予備知識があったりOSSコミュニティーに貢献したりしていないと参加してはいけないのでないかと考えている人もいるかもしれませんが、私が今まで何回か参加した感じでは全然そんな閉鎖的な雰囲気はないですね。まだ、一度も勉強会に参加したことのない人にも自分の興味のあるテーマの勉強会に是非一度参加することをお勧めしたいですね。
とにかく、勉強会では新しい知識を得られるということはもちろんですが、書籍を書いたり、OSSの開発をされているようなトップレベルの技術者と直接気軽に交流できるチャンスです。このような勉強会に無料で参加できるとはなんと素晴らしいことなのでしょうか。この様な機会を作ってくださっているDevLoveの運営委員の方々には本当に感謝いたします。

勉強会参加レポート

今回は全体の基調講演を除いて「陽」と「陰」の二つにセッションが分かれていました。どちらかというと陽の方が書籍に従ったDDD入門者向けの内容、陰の方が実適用や独自のアイデアなどより高度な内容という位置づけだったようです。私は最近業務でDDDから遠ざかっていたところがあったので、復習の意味もこめて、基本的には陽のセッションを中心に参加しました。以下、私の参加したセッションについて簡単にレポートさせていただきます。

陽第１枠、Building Blocks DDDと愉快な仲間たち（都元ダイスケ氏、id:daisuke_m）

DevLOVE Beautiful Development - 第一幕 陽の巻
パターン言語としてのDDDの基本的なビルディングブロック（基本要素）となるDDD本の第2部の内容を中心に説明されました。とにかく盛りだくさんの内容を短時間に詰め込んだ非常に内容の濃いものでしたので、DDDがまったく初めての人はちょっとついていくのが大変だったかもしれません。どのパターンも非常に大切な内容なので、しっかりと復習しておきたいところです。
個人的には以下の部分が特に興味深かったところです。

エンティティやモジュールなど基本的なところも結構見落としていたところがあったと思ったので、日本語訳が出るこの機会に復習しておきたいと思いました。

陽第２枠、ブレイクスルー体験記（渡邉健太郎氏）

Beautiful Development ブレイクスルー体験記
DDD本の第3部のテーマであるより深いモデルの構築について、銀行のシンジケートローンの業務にDDDを適用する例を本の内容にそって解説されました。

つまり、良くあるオブジェクト指向設計の本のように単に名詞を抜き出してクラスを作るとか、フレーワークの規約に従ってクラスを作るといったやり方では決してあるべき深いドメインモデルは構築できないのです。この例ではお金の債権者の引き受けの割合を円グラフの扇形（シェアパイ）に見立て、そのシェアパイを不変で演算可能なバリューオブジェクトとして設計するというブレークスルーの例が紹介されています。そういうブレークスルーが得られることでコードは業務の言葉（ユビキタス言語）で見通しよく記述できるようになるだけでなく、仕様変更にも強い設計となります。こうした、ブレークスルーは方法論やツールで機械的に得られるものではなく、時間をかけてリファクタリングをした末にようやく到達できるのであるという点も見逃せません。こういった試行錯誤こそが本来のエンジニアリングの醍醐味ですから。
なお、スライドにも明記してありますが、発表者の渡邉さんは大手SIer、すなわち「ITゼネコン」に勤務されているということで、現実上、普段お仕事ではなかなかこういった理想的な仕事ができないという悩みについても語られていました。
規模こそ違え、私の会社もそういうところがありますから、多くの場合、理想とかけ離れた仕事をせざるを得ないという現実があります。同じ業界で働く技術者として「いつか月にロケットを飛ばす仕事がしたい」という言葉にものすごく共感いたしました。

陽第３枠、DevLove DDDBC（和田卓人氏、id:t-wada）

DevLOVE DDDBC
今ではTDDときのこ本で有名な和田氏ですが、もともとは私と同様にOO厨の方だったのですねw。講義の前半ではDDDを理解する上で前提となるオブジェクト指向に関する何冊かの書籍を紹介されました。この点は実は見落としがちなのですが、DDDを理解する上では非常に重要なポイントで、オブジェクト指向の基礎知識なしでDDD本を理解することは不可能と思います。アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)などこのブログで既に紹介している書籍もありましたが、私もまだ読んでいない書籍も結構ありましたので以下のつぶやきとなりました。

最後の10分は紙が配布され、隣の人とペアで実際にモデリングをするという実習になりました。とても10分では深いモデルに到達できませんでしたが、今後機会があればモデリングに挑戦してみたいと思います。（ただし、DDDの深いモデリングはユースケースというか具体的なコンテキストを前提としないと難しいところがありますね。普通にクラス図を描くだけでは単なるオブジェクト指向設計のモデリングになってしまいますので。）
ちなみに、今回の講義資料はTDDの資料のTをDに置換して作ったとおっしゃっていました。確かに見かけ上TDDとDDDはそっくりですね。（TDDの最後のDはDevelopmentのDなのにDDDのDはDesignのDなので文字通りの意味は異なりますが。段階的に品質の高い設計に向かっていくという意味では実際両者で共通しているところも多いとも。）

陰第４枠、ブレイクスルーと文学（佐藤匡剛氏）

ブレイクスルーと文学 - The Breakthrough and Literature
佐藤匡剛氏は以下のすばらしい紹介記事で、日本でDDDを広めるきっかけを作られた方で、
[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場
また、S2DomainModelなどのオープンソースでも知られています。
[お知らせ] S2DomainModel リリース | Ouobpo
現在はSoftware AG社にてSOAやESBなど大規模なシステムの基盤となる製品のコンサルタントをされていることもあり、前半は腐敗防止層などDDD本でも最後のパートで出てくる大規模な設計に関するパターンを紹介されていました。また、それ以外にもDDDの設計に対する基本姿勢に対する考え方を説明されました。

それで、

ドメインモデルとは常に到達不能な不在の中心

その不在の中心へ向かう運動こそがドメイン駆動型設計

という話の展開になり、そこからモーリス・ブランショの文学論へと議論が発展しました。かなり深い内容で、うまく解説できないのですが、興味のある方は以下のビデオをご覧ください。

キーノート、戦略的設計入門（和智右桂氏、id:digitalsoul）

最後のキーノートセッションは全員合同でDDDの日本語版の作成者の一人である和智右桂氏より、第4部の戦略的設計について説明がありました。この講義の内容については、非常にわかりやすく解説されている是非以下のエントリーをご覧ください。
戦略的設計入門 - Digital Romanticism
私の主な感想としては、

ということで、何かにつけて日ごろの自分の持論を結び付けてしまっていますがw。
その後、ご本人にうかがったのですが、第２枠の渡邉さんと同様に、和智さんもSIer勤務で業務ではDDDとはかけ離れたマネジメントの仕事をされているとのこと。その意外な事実を知って出てきたつぶやきが以下のとおりです。
このつぶやきに対してid:Rintaさんが技術の需要供給ギャップと、今時のプログラマに求められる資質がソレってちょっとどうなの？という話 - おろかな日々で書かれているように返信してくださったのですが、私のつぶやきはそういう気持ちから出たものです。

なお、今回は、勉強会用に先週購入したばかりのMacBook Proを会場に持ち込んでの参加だったので、メモ代わりにTwitterでたくさんツイートすることができました。
勉強会中の私のツイート
また、今回の勉強会の内容については以下もご覧ください。
4/9 DevLOVE Beautiful Development つぶやきまとめ - Togetter
（Twitterのハッシュタグは#devlove OR #devlove0409 until:2011-04-09で検索するとよい。）
また、私より先にいち早くレポートブログエントリも書かれていますので以下もご参照ください。
4/9 DevLOVE行ってきました - ShiroKappa Blog
errorlevel99: ソフトウェアの核心にある複雑さに立ち向かう、準備をしてきた
感想「Beautiful Development ソフトウェアの核心にある複雑さに立ち向かう」 - yujiorama の日記
「DDDカンファレンス」にいってきた！ | こやなぎのブログ
DevLOVE Beautiful Development( #devlove, #devlove0409, #DDDjp )参加メモ - memoの場

DDDに対する熱い思い

今回のテーマはDomain-Driven Design(DDD、ドメイン駆動型開発）でした。これはソフトウェアの核心である業務領域の部分に最も重点を置いて設計をしましょうという考え方です。もともと、DDDの考え方は今から8年も前に出版されている

Domain-Driven Design: Tackling Complexity in the Heart of Software

Domain-Driven Design: Tackling Complexity in the Heart of Software

で広く知られるようになった考え方ですが、今年のQCon Tokyoで著者のEricEvans氏の来日が予定されていますし、それに合わせて待望の翻訳書が出版されているということで、日本でもようやくブーム（？）が起こるのではないかという予感がしています。
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

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

DDDについては私自身も強い思い入れがもあって、このブログでも何回か言及してきました。
日本と欧米ではPOJOの意義に対して微妙な解釈の違いがあるような気がする - 達人プログラマーを目指して
SIerがExcel→Javaのコード自動生成をPGに押し付けるのは善か悪か？ - 達人プログラマーを目指して*3
今のSI業界もリファクタリング可能だと思います - 達人プログラマーを目指して
日本だとSI業界はゼネコン構造でソフトウェア技術からはかけ離れた仕事というイメージが強いですが、この場合の技術はいわゆる言語やツールなどの狭い意味での技術ということだけでなく、DDDのような業務のオブジェクト指向モデリングに関する技術が欠如しているということがむしろ問題であると私は考えています。一般的に業務要件や業務仕様とは画面の文言やテーブルの項目などといった細かい仕様が記述されたExcel表を意味することが殆どであり、ドメインモデルのような業務の本質を探り出すようなことは殆ど行われません。*4これでは、本当に設計能力のあるプログラマーが力を発揮できる場所がツールや画面周りといった業務から見れば周辺の機能になってしまっているということであり、本当に大切な基幹の業務ロジックを実現する部分で活かされることがほとんどありません。
DDDの日本語版が出版される今年こそ、SI業界に対するこうした残念な状況を改善していくきっかけの年にすることができればと考えます。そして、本当の意味でビジネスの人とプログラマーがよきパートナーとしてITのソリューションを創造するような世の中を作っていきたいと願います。

*1:私のDevLove勉強会初参加は1月に行われたGroovyの勉強会でした。Groovy言語とAspectJの人気が今ひとつな本当の理由 - 達人プログラマーを目指して

*2:Upstreamの中継を通してリモートから参加された方も大勢いらっしゃったようです。

*3:Excelのツールなどに技術力を発揮しているのに肝心のドメインモデルは自動生成で頭を使わないという発想でDDDとは逆の発想になる。

*4:複雑で役に立たない大量のUML図などをモデル駆動という名目で生成する場合はある。DDDでは本当に必要でプログラムと対応したモデルしか作成しません。モデルを作成するのはプログラマーだからです。