connpass
http://connpass.com/event/2445/
以下の書籍をターゲットとした読書会なのです。
 | エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) (2011/04/09) エリック・エヴァンス 商品詳細を見る |
場所は鶴見区の矢向地区センター（Ｃ会議室）です。
自宅からだとDoor To Doorで30分くらい。近いのが良いですね。
参加者は9人かな。そのうち8人が顔見知りです。
というのも元々、身内でDDD本の読書会をやろうっ、って流れだったのです。
んでも、新規で1名応募があって良かったと思います。新しい風が入るの、重要。
ちなみに、私がDDDに最初に興味を持ったのは、「実践テスト駆動開発」という書籍を読んでいたときでした。
 | 実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION) (2012/09/14) Steve Freeman、Nat Pryce 他 商品詳細を見る |
通称、GOOS本。
このGOOS本の読書会がグロースエクスパートナーズ株式会社さんであったのですが、訳者の和智さんも参加されてました。
和智さんはDDD本の訳者でもあるのですが、「DDD本の知識はGOOS本の前提になっている」とのこと。
あと参加者さんも「DDD本読んでるよ」ってことだったので、これは是非読まねば、と思ったのがキッカケ。
そんときのブログはこちら。
3/2(土) 「第n回GOOS（日本語版）読書会」に参加してきたのでブログにメモを書いてみました。 makopi23.blog.fc2.com/blog-entry-55.…
— makopi23さん (@makopi23) 2013年3月2日更にGOOS本の読書会の約2週後に開催された「java-ja.ddd」というイベントが、DDDに対する興味に火を付けたッ！
3/22(金) 「java-ja.ddd」に参加してきたのでブログにメモを残しておく。 makopi23.blog.fc2.com/blog-entry-63.…とても有意義な内容のイベントでした。感謝。
— makopi23さん (@makopi23) 2013年3月24日GOOS本の読書会のあとにすぐDDD本を買って読んでたんですが、この日の講演は私にとってすごく刺激的でした。
おまけに、和智さんにDDD本の見開きにサインを戴いた！
んでも本の分厚さから、独りで読み進めるのはなかなかツライ。。。
ってなことを @naopi さんや @grimrose さんと話してたら、@naopi さんが読書会を企画するとのこと！
「おおおお！」ってなカンジでこの日を迎えました。
ちなみに「アジャイルサムライ」のP.229にも「DDD本は必読」としっかり書いてありますね。
 | アジャイルサムライ−達人開発者への道− (2011/07/16) Jonathan Rasmusson 商品詳細を見る |
そういう意味でも横浜道場の門下生は読まざるを得ないっ！
■アジェンダ by @naopi さん
@naopi さんがアジェンダのスライドを作ってきてくださいました。感謝！
今回は「まえがき」から読み始め、「輪読＋ディスカッション」を繰り返す横浜道場方式で進めました。
以下、個人メモ。
---
■ドメインとは
・書籍にいきなり「ドメイン」って出てくるけど、ドメインってなに？どっかに定義書いてあったっけ？
・P.xivの真ん中あたりに「複雑なのはドメインそのもの、すなわち、ユーザの活動やビジネスなのである」と書いてある。
・でも、「ドメイン ＝ ユーザの活動やビジネス」という定義ではあまり使われていないっぽくね？
・P.519の用語解説には、ドメインの定義として「知識、影響、または活動の領域」と書かれている。
・ここでは開発者とユーザが共有すべき「共通概念」といったカンジかなぁ。
■DDDの本質を説明するには
・困るのは、DDDをエラいさんに説明したときに、「業務知識って重要だよね」という一言で終わること。
・P.xvに、「開発がイテレーティブである」ことが前提条件とされている。
→ 「イテレーティブ」がすっ飛ばされて「ドメイン大事」とかいわれても、それは間違い。
■ドメインエキスパートとは
・ドメインエキスパートは、モデルまで一人で作れなくても良いのでは。
→ 開発者とユーザが密接に関わりながらモデルを作ることができれば良い。
・原著では、ドメインエキスパートは複数形で書かれている。
→ ドメインエキスパートはその業務の専門知識をもつ人。複数の場合も有り得る。
■ドメインモデル
・開発者とユーザの共通言語である。
■モデルと曖昧さ
・アジャイルプロセス協議会では、「曖昧さを極限まで無くせ」と提唱している（らしい）。
・「抽象化」が間違った方向にいくと「曖昧性」に向かう。
・本来の抽象化は、「余分なものを削ぎ落とした核の部分を作る」こと。
■DDDはウォーターフォールで出来るか？
・書籍には「開発がイテレーティブである」ことが前提条件、と書かれている。
・ウォーターフォールだと、上流工程でモデルを作りきってしまう。修正できるか？
・「リファクタリング」でモデルを修正すれば良いが、「リファクタリング ＝ 手戻り」となると最悪よね。
・モデリング・設計・実装が分断されないほうが良い、と書籍にはある。
→ 分割発注の場合とかどうすんのやろ。。。
・ウォーターフォールの弊害についてはP.14に書いてある。
■ドメイン駆動チーム（P.xix）
・開発者はドメインエキスパートといつでも会話できる状態にないといけない。
■現場で、モデルを作っていますか？
・ER図は作っている。
・絵レベルで作成、お客さんに説明する。UMLとか厳密な書き方はしない。
・絵で書いたモデルは、その場限りで廃棄するものも出てくる。
---
最後に振り返りでKPT書いて、終了となりました。
そのあとは近場で飲み会。お酒とお好み焼き、みんなで美味しくいただきました～
★感想：
今回は「まえがき」で終わってしまい1章に入れずじまいでしたが、いろいろ議論出来たので良かったと思います。
ただこの本の分厚さからすると輪読方式だと難しいかもね、って話は、その後の飲み会でも出ました。
JUnit写経会のように、事前に対象範囲を読んでくる方式にして、当日は黙読程度にとどめてディスカッションをメインにしたほうがいいのかもしれない。
いずれにせよ、この本を最後まで読みきりたい。
んで、読むだけじゃなくディスカッションで理解を深めたいし、写経とかもやりたいなぁと思ってます。
主催の @naopi さん、参加者の皆さん、ありがとうございましたー
おまけ
え？みんなDDD T シャツ着てない？ マジで？ #DDDSheep twitter.com/aeg/status/343…
— Eiji Itoさん (@aeg) 2013年6月8日DDD Tシャツを着て参加された @aeg さん！
やべぇ、欲しい。。。
