connpass（告知サイト）
http://connpass.com/event/1934/
Togetter
http://togetter.com/li/463570
恐るべき人気。申し込み開始初日で200人くらい一気に埋まったんじゃないでしょか。
かくいう私も補欠30番目くらいに並んでて、当日なんとか繰り上がって参加できました。
場所は六本木ヒルズ森タワー、GREEさんです。参加者は150人くらい？でしょうかね。
ちなみにGREEさんから無料のビールとピザまで振舞われました。GREEさん流石！ありがとうー
この日のテーマが「ドメイン駆動設計」ということで、前々から楽しみにしていました。
というのも、先日のGOOS勉強会で和智さんや参加者さんからも以下の書籍をオススメされたのです。
 | エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) (2011/04/09) エリック・エヴァンス 商品詳細を見る |
ということで、ちょうど買って読んでる最中でした。
ちなみにGOOS読書会に参加したときに書いたブログはこちら。↓
3/2(土) 「第n回GOOS（日本語版）読書会」に参加してきたのでブログにメモを書いてみました。 makopi23.blog.fc2.com/blog-entry-55.…
— makopi23さん (@makopi23) 2013年3月2日以下、自分用に取った講演メモ。
■第一部 ざっくり DDD 入門！！
・発表者 : 和智 右桂さん
ざっくり DDD 入門！！ from Yukei Wachi
■最近、「組織パターン」という書籍の翻訳をやっている。発売は6月くらいになるかも。
■今日のDDDは、実践部分は増田さんが話すので、和智さんはエッセンス部分を話す予定とのこと。
■書籍「ドメイン駆動設計」の前書き：「ソフトウェアは複雑だ」
・2003年に英語版をエリック・エバンスが書いた。
・日本語版の翻訳版が長いことでなかった。２０１０年くらい。
・サブタイトルに「ソフトウェアの複雑さに立ち向かう」とある。
・まえがきに「複雑なのはドメインそのもの」とある。
・テクノロジーの難しさはあるが、業務の複雑があるだろう、というのがドメイン駆動設計。
■業務知識とは？
・いろんな側面がある。ではシステム開発をする上で必要な業務知識とは？
- どういうデータが流れているんだろ？
- どんなルールがあるんだろ？
- どんな演算がされているんだろ？
- システム間連携でどういうやりとりをしているんだろ？
・これら業務知識を学ばねばならない
■自社ならまだマシ。お客さんの業務を学ぶのは手探りになる。
■自分が手がけたシステムで、「このシステムのことがわかった！」と思った工程はいつか？
・和智さんは結合テストが多いとのコトで、コードをガリガリ書いている時はよくわからなかったとのこと。
・お客さんの視点に立てるのはけっこう後の工程。
・ちょっと怖いなぁと思うのは、よくわからないままソフトウェアを作ってること。それで本当に大丈夫なの？
■業務知識を反映させることで、ソフトウェアを柔軟に変更したり拡張したりできるようになる。
■業務知識をそれほど反映しないソフトウェアとは？
・8割くらいはトランザクションスクリプト（※１）で書いている。
・モジュール化は処理の種類に行われるので構造が安定する。
・でも、その中で何をやってるかは、コードを読まないとわからない。
・ただ構造が安定するので30～40人くらいだと、ガバナンスが利き易いメリットはある。
・ただしこれだと重要なドメインが埋もれてしまう。
■※１
「トランザクションスクリプト」という単語を知らなかったのでググってみた。
このへんの記事が参考になると思った↓。
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」
http://d.hatena.ne.jp/higayasuo/20080519/1211183826
[ソフトウェアアーキテクチャ][PofEAA]トランザクションスクリプト
http://d.hatena.ne.jp/asakichy/20120612/1339451426
■例：
・ホテルは満室でも、キャンセルを見込んで予約を止めない。
→ オーバーブッキングを見込んで多めに予約を受け付ける。
・これをトランザクションスクリプトで描くと、このようなIF文がかかれる。（DDD本のP.18あたりのコード参照）
・重要なロジックなのに、他のコードに埋もれる。いろいろな些末なロジックに埋もれる。
・これじゃあ業務知識を反映できているとはいえない。
・じゃあどうするかというと、「制約をコードの中で可視化する。」
・オーバーブッキングポリシークラスとして抜き出し、コードで可視化する。
・ただし極限まで突き詰めるといいのか、というとそうじゃない。バランスが重要。
・バランスを考慮しない設計として、「エンタープライズFizzBuzz」というのがある。これが良いわけがない。
■あらゆるIF文をオブジェクトに変えよう、というのは正しいのか？
→ それは間違っている。柔軟でもなんでもない。
■複雑なドメインの設計は、モデルを元にしてください。
・ドメインとは、モデルの専門家によって整理され単純化された世界
・整理も大事だし、単純化も大事。
・ドメインエキスパートとモデルを共有しましょう。
・ドメインの専門家といっぱい会話して、モデルを共有しましょう。
・エリック・エヴァンスのホームページに、どうやればいいかが書いている。本には書いてない。
■Domain Language Model Exploration Process
出展： http://domainlanguage.com/ddd/whirlpool/
・Whirlpoolでシナリオから入る。どういうことをやらないといけないのか。
・そのあとモデルを描く。そのあと特殊ケースとかをシナリオに戻す。
・それを２～３日やって、コードを書きたいなぁとなったら、 「Code Probe」に入る。
・コードを使ってモデルを通してみる。
・それをやってみると、大丈夫そうなモデルが、落ちたぞとかわかる。そうやってシナリオに戻ってくる。
・それを繰り返す。
・そろそろわかってきたから、本当か確かめてみるか、みたいなノリ。
・イテレーティブかつインクリメンタル。
・これをウォーターフォールにハメるにはテーラリングが必要かも。
■モデルだけ作って後はよろしく、はダメで、それをソフトウェアに反映させましょう、というのがドメイン駆動設計。
■ところで、「モデル」と言われてどんなものを思い浮かべますか？
・とあるエンジニアは、ロバストネス図を描いていた。
・でも、ここで考えるのは業務のモデルなので、シンプルに考えるとER図になることが多い。
・それだけではなく、ルールとか重要な演算とか特別な仕様もオブジェクト指向の力を借りて表現したものとして「モデル」を考えるとわかりやすいんじゃないか。そういうのが埋め込まれたER図として考える。
■ドメインエキスパートとは
・実際に業務を回している人よりも、全体として何が起こっているかを把握している人。
■質問１：
ドメインエキスパートと会話しよう、とあったが、実際そんな人いるのか？
■質問１の回答：
・ドメインエキスパートを探すのは大変、とエリック・エヴァンスも言っている。そんな人はきっと忙しいだろうし。
・でも、そういう人はいる。どうやって探すかは和智さんもいい方法は知らない。
・システムの運用が回ってればそういう人は見つかりやすいかも。
・運用をアウトソースしてると、見つからなかったりするかも。
■質問２：
業務のキーマンだけどシステムに詳しくない人はドメインエキスパートとは呼べないか？
■質問２の回答：
・コードは書けなくても、データの構造は少なくともわかってたりする人とかはドメインエキスパートと言える。
・本の中だけでいうと、何を作るかの先に、作ったものがどれだけ価値をもつか、という話がある。
→ そういう話はドメイン駆動設計からは外れてしまう。
・いわゆるオブジェクト指向のクラス図が、先ほどいったER図のようなもの。
■質問３：
ドメインエキスパートは複数いるのか？
■質問３に対する回答：
・プロジェクトマネジメント観点からいうと一人に絞りたいというのはある。
・でも業務によるが、これはこの人、というのがある。なので複数の場合もある。
・ドメインエキスパートはプログラム書く人と別の人、とあるが、同じ場合もある。
・ドメインエキスパートはその業務の専門知識をもつ人。その人がJavaやDBのエキスパートのこともありえる。
■質問４：
そもそもドメインが整理されていない会社があって、整理しましょうとなったら、誰にやってもらえばいいのか。
■質問４に対する回答：
・DDDの本でいうと４部に戦略的設計というのがあって、複数のドメインをどうすれば良いかが書かれている。
・具体的に誰が意思決定をするのかは一概に言えないが、ある概念が同じ意味を持つのはどこまででしょう、
というのがポイントかも。
・「Conwayの法則」というのがある。
→ 「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」
・システムは人の集団の構造に似てしまう。大きな会社では部署が分かれているので、部署がドメインの境界になるのもありえるのでは。
■質問５：
ドメインエキスパートがいる時点でブルーオーシャン（※２）ではないのでは？
（※２）ブルーオーシャンとは：
2005年2月に発表されたフランスの欧州経営大学院教授のＷ・チャン・キムとレネ・モボルニュの著書
『ブルー・オーシャン戦略』により提唱された市場の定義。
まだ誰も参入者がいない競争のない新たな市場空間のことを指す。
出展： http://d.hatena.ne.jp/keyword/%A5%D6%A5%EB%A1%BC%A5%AA%A1%BC%A5%B7%A5%E3%A5%F3
■質問５に対する回答：
・そうかもしれない。
・なにか新しいものを作る時、何を作るかを当然考える。
・複数人で考えるときは、議論をする。
・その議論の過程を結果として残しつつ、ソフトウェアに反映していくのが健全だと思う。
■参加者からの発言
・ドメインを考えるとき、物流より図書館を想像するようにしている。
・物流だとゴツイおっさんが無理なことを言ってくるイメージ。
・図書館だとかわいい司書さんがいてヤル気でるなぁ、みたいな。
★休憩時間に和智さんからDDD本にサイン貰いました～
和智さんは人柄がとても穏やかで、物腰も丁寧です。私が尊敬するエンジニアの一人です。
第二部 ガッツリ DDD 実践編！！
・発表者 : 増田 亨さん
リッチなドメインモデル 名前探し from 増田 亨
■みなさんが持ち帰れる話でないかも。。。
■トランザクションスクリプトを越えてリッチなドメインモデルを作ろう。
・キレイ事じゃないので上手くいかないことがある。
・名前とか言葉が気になっている。そこの捉え方が上手くいくと、仕事も上手くいく。
■ちなみに、DDD本の原著は「ドメインエキスパート」はほとんど複数系になっている。
■「DDD難民」という言葉もあって、「DDDは分かり難い」と言われていた。
・でも、私はそう感じたことがなかった。
・それは、前提となる経験とか知識がDDD難民の方と違っているんだな、と気づいた。
・P.3の前提書籍の知識がないと、読んでもピンとこない。
→ オブジェクト指向でソフトウェアを作る話がこれらの本にあって、それで初めてDDDがわかる。
・DDD本だけ読んで素晴らしいことがわかる、ということはない。
・前提書籍も嗜み程度には触っといたほうが良いのではと思っている。
■私がドメイン駆動設計への道を歩んだ過程
・最初は、大きな泥団子。
・このプロジェクトが火を噴いた。
・そこに呼ばれて「なんとかしてくれ」と言われたのがドメイン駆動設計を必死に勉強するきっかけだった。
■リッチなトランザクションスクリプト
・非常にシンプルなドメインモデルにしただけで、どこで何をしてるのかが見やすくなった。
・型安全の恩恵を受けれるようになった。
・でも、「ドメイン駆動設計」を読んでると「なんか違うな」と思っていた。
→ いろいろやってみようか。
■リッチなドメインモデル
・これが今日のテーマ。
・業務の言葉で組み立てる。
・小さなオブジェクトを大事にする。
・ただ、「そういうふうにしないとうまくいかない」と言うつもりはない。
■なぜこうしたかと言うと、お客さんが泥団子をメンテするコストを払えなくなったから。
■ドメインモデルの開発
・モデリング
・プログラミング
・リファクタリング
■イテレーティブというより、毎日やっている。
・過去のコードは絶対汚い。
・どうせ弄るんだったら、こうやれば保守しやすくなるなあ、と一日に何回もそれを回す。
■名前に違和感がある、という感覚が改善されてくると、ドメインオブジェクトもよくなってくるなぁ、と感じた。
■プログラミングは名前探し
■コードを書くとなると、嫌になるほど名前を考えないといけない。
・これを業務の言葉で埋め尽くす。それにどれだけこだわれるか。
・ソフトウェアのネイティブな感性でなく、業務に如何にこだわって合わせるかが、ドメイン駆動設計。
■ぶっちゃけ、ドメインエキスパートなんていやしませんよ。
・でも、自分より業務を詳しく知ってる人はたくさんいる。
・情報源としてのドメインエキスパートはいる。その人と仕事をしないとうまくいかない。
・ただし、彼らの言うとおりに作っただけでは、良いものはできない。
■業務の言葉をオブジェクトで書くのは、技術屋としては難しい。
・でも、これを「面白い」と思えないならドメイン駆動設計はやめたほうがいい。
・ソフトウェア開発であれば必ずドメイン駆動設計でやれ、とは思っていない。
・でも、お客さんに価値を届けたいならやったほうがいい。しかし自分に合うかどうかは別問題。
■基本データ型を１個１個ラッピングしていく。例えばlong型フィールドだけもった番号オブジェクトを作る。
■聴衆からの質問： 日本語で名前つけるか？
・増田さんの回答：全部英語です。
■基本的にはかなり小さいオブジェクトにして、ルールとか情報をラッピングする。
・すごく小さい単位。そういうオブジェクトをたくさん作っていく。
・ファンダメンタルなオブジェクトを如何にうまく整備して育てていくかが、良い仕事ができるポイント。
■設計パターン
・一番走るメインのルーチンはトランザクションスクリプトのようなものとなる。
・そこにたくさんのロジックを書くのではなく、委譲する。そのようなトランザクションスクリプトとする。
■やりとりするオブジェクト
・出来事（イベントオブジェクト）
・記録
・通知（記録しただけじゃなく、通知する）
・参照（エンティティパターン； 識別番号でたぐっていくと、識別番号でタグづけされた情報を取得できる）
■オーバーブッキングポリシーは業務でそのままつかってるから、ポリシーとして抜き出すのは設計としてアリ。
・そうじゃなく、業務側がそういう認識をしていない場合は、、ポリシーパターンとして抜き出すとたいてい失敗する。
・ムリに抜き出すと、仕様変更とかタイミングがずれる。そこでヘタに共通モジュールにしてると変更が大変になる。
■コードの重複を避けるのに共通化するのはよくあるが、業務として本当に必要かは、こだわってほしい。
・言葉は、業務とか会社で違ってくる。これを如何にオブジェクトとしてソフトウェアにするかが超重要ポイント。
■役に立つドメインオブジェクトとは？
・だいたい共通の性格がある。
★良い名前
★小さく作ってある
★ばらばらにする
→ これらを意識してやるようになってから、仕事が楽になった。
■良い名前の見つけ方
(1) 語彙を増やす
・子供が言葉を覚えるように、エンジニアも調べたりして語彙を増やすこと。
・人とのインタラクションを持たないと語彙は増えない。
・プロジェクトの初日に、ぜったいに語彙を見つけにいくべき。
・例えば、サービスについて解説している入門編、ガイドブックとか、ヘルプ画面とかから探す。
・パッケージ開発なら、類似のパッケージソフトのカタログから語彙を探すのも有効。
・これらの語彙を英語名にする。初日に、この英語版を探すべき。
・良い語彙を見つけてしまえば、クラス名とかに苦しむことは減る。
・初日にクラス名とかの有用な情報を手に入れるために、その分野の解説書とか入門書を読みなさい。
→ 初日に丸一日かけてもよいからやるべき。
・英語力はそれほど必要ない。
・自分がクラス設計するのに便利なものを見つけたいが、便利なものは山ほど見つかるので活用してほしい。
・人と会話するのが良い。出てくる言葉の頻度とか、会話に興味を示してくる人とか、関心度とかが分かるので。
・人は、そういう濃淡で仕様変更を言い出すに決まっている。なので、その人が何に興味があるかを早めにに知る。
・初めてのドメインでも早めにキャッチアップするのが大事。銀の弾丸まで行かないがが、凄く役に立つ。
(2) 正しく使う。
・これは難しい。
■こういう調査はチーム作業。対人は苦手なのでプログラミングだけやります、という人はNG。
・でも適材適所はある。全員がこれをやるべき、とは言うつもりは無い。
・相手の表情の変化に気づかないエンジニアがいる。そういう人とは仕事やりたくない。
■小さく作る
・クラス： 50行以内
・メソッド： 3行以内
・パッケージ： 10ファイル以内
これを越えたら分割を考える
そうはいっても、メソッド3行は難しい。。。実際にやってみると大変。
でも、この世界を味わってみることは絶対プラスになる。
■ドメイン層でtry-catchが起きるのは、ドメインモデルとしてはおかしい。
■3行メソッド
・メソッドを業務の言葉、業務の流れで書いていると、導いてくれる。
→ 追いかけるのが凄く楽になる。
■コンピュータのパワーアップとIDEの進化の恩恵にあずかる。メソッドの呼び出し元と呼び出し先を行ったり来たりとかは、今の開発環境だとわりと簡単にできる。
■実践の小技
・HowよりWhat。汎用部品を専用部品にする。
■dayOfFinalAlertというメソッド名の例：
・業務で言ってくる仕様とリンケージさせてメソッド名を付けるべき。
・その際、メソッド名を汎用的に「finalAlert」としようとするエンジニアと戦わなければならない。
・でも、「day of」が業務を的確に表すならば、「finalAlert」じゃなく「dayOfFinalAlert」とすべき。
・1日から1週に仕様変更になったら、「day of alert」から「week of alert」にメソッド名をを変えるべき。
■汎用部品を専用部品に
・Stringとかの汎用データ型をラッピングして、クラスにする。
・何でも屋を、目的特価・業務固有にする。再利用を目指すんじゃない。
・業務の根幹となるものは、他に持っていけるのはおかしい。
・「再利用」のための部品化ではなく、「業務」のための部品化を考える。
■enum
・タイプごとに振る舞いを持たせられる。
・業務的にはenumで押さえておくことが非常に多い。
■if ○○=nullとかの代わりにMissing Objectパターンを使う
■Map, Set
・パターンマッチをかけにいって、keyからvalueを取り出すようにするとifの必要性が減る。
■JavaのBean Validatorはすごく強力。
・IFをきれいさっぱり無くすことができる。
・仕組みさえわかってしまえば有効。
■コードでNULLが飛び交うことはあり得ない。その前提でコードを書きましょう。
・契約による設計、を意識する。
・AsertでNULLが来ないことを表明しておき、IFとかでチェックしない。
・このやり方は是非取り入れた方がいい。
■Collectionはそれ単独でオブジェクトに詰め込む。
・ファーストクラスコレクションだけでもやってみる価値がある。
■CollectionフレームワークのAPIは便利になっている。VMのバージョンが変わるたびに便利になっている。
■一手間かければforやifは大分減らせる。でも、なんでもかんでもやればいいわけではない。
■setterを使わない
・setterで状態を変えるな。コンストラクタで最初に情報は指定しておけ。
・そもそもsetやgetは業務の言葉じゃない。
・setterやgetterは必要なときに作る。（全フィールドに一律用意しない）
例えば、フレームワークでsetterが無い、と怒られてから作る。
■getterを使わない
・getしてデータを取ってきてから何かを処理するんじゃなく、そのオブジェクトに処理をまかせるべき。
・ロジックとデータを分けるな。
■パッケージ階層はフラットに
・構造がわかってない初期にパッケージを切ったり階層を作ってしまうと、あとで大変。
・役割分担が変わっても他に影響が少なくなるようにする。
・ドットつなぎになるコードは、その階層構造に依存してしまう。
・名前で見つけにいけるようになると、階層構造は鬱陶しくなる。
→ できるだけバラバラにしておいたほうがいい。
■継承は控えめに
・継承したほうが楽そうだから、というのはけっこう痛い目にあう。
■パッケージスコープを好む
・import文も少なくすべき。
・ドメイン設計だとそれほど呼び出す必要がないはず。importが多いと、「設計がおかしいのでは」と思うべき。
■第三部 俺にもちょっと DDD 喋らせろ！！
発表者 : @t_wada さん, @j5ik2o さん
LTです。22時から開始でしたが、こちらも興味深いお話でした。
t_wadaさんは書籍「SQLアンチパターン」から「マジックビーンズ」を取り上げ、DDDに結び付けていました。
先日のDevloveで和田さんの講演を聞いて、この書籍を買いました。まだ全然読めてないので今後読む！
あと、最後の5分で増田さんが関数型言語についてトークされてました。
私もHaskellの勉強会に2年くらい参加してて、いろいろ思うトコありですが、それはまた今度。
★感想：
さすが一瞬で満員になるようなイベントだけあって、質が超高い。話の内容が濃い。
DDD本の最初の方しかまだ読んで無い私でさえ、DDDの良さを十分に感じられる内容に纏まってました。
あとは、この書籍をきちんと読みたいと思います。しかし分厚いなぁ。。。
一人だとつらいので、読書会とかあるといいのになぁ。。。
最後に発表者さま、会場提供のGREEさん、java-jaスタッフさんはじめ関係者さん、大変有意義な場を提供いただきありがとうございました。
