技術書の歩き方勉強会「達人プログラマー」編 で登壇してきました

技術書典のご縁で @takahashim さんにお誘いいただいて
技術書の歩き方勉強会「達人プログラマー」編 で登壇してきました。

トークセッションの自己紹介でもお話したとおり、
新卒の頃に本の編集者を目指していたこともあったのですが
まさか技術本の紹介イベントでお話することになるとは、ちょっと不思議な気持ちでした。

トークセッションでお話しした内容などは #TechBookWalk で実況されています。

イベント開催にあたって、人数配分やハッシュタグ、イベントタイトルなどで入れ知恵をさせていただいてうまくハマった施策もあっておもしろかったです。

いくつか特によかったなと思う点を挙げておきます。

参加人数とキャパ

最初は募集40人から始めてすぐにいっぱいになりましたが、広い会場をご提供いただいたspeee様のおかげで100人まで増やすことができました。
東京のイベントでは6割近くドタキャンが発生することも少なくないのですが、会場がいっぱいになるまでご参加いただけてよかったです。

発表内容について

久しぶりの登壇でしたがちょっと練習して臨んだのであまり緊張せず発表ができてよかったです。
@moro さんの発表の「本と出会うタイミング、コンテキストが重要」というお話が印象深かったです。
トークセッションは初めて経験する発表形式でしたが、
@takahashi さんの絶妙な司会と主催 @shimada さんの鋭い引用に引っ張っていただいて、
好きな本について好き勝手お話させてもらうことができとても楽しかったです。
最後に、いつも良い技術書を出してくださるオーム社さんに拍手が沸き起こる暖かい会場でした。

#TechBookWalk

ハッシュタグでたくさんの方に実況していただいてTLにも会場の雰囲気が伝わってよかったです。
気になる技術書があったらまたこのハッシュタグを使っていただけたらと思います。
実は事前に日本語ハッシュタグで質問内容を募集したりもしていたのですが全然利用されなかったので、
イベントのハッシュタグは分散させてはいけないなと反省しました。

自分はまだ達人プログラマーには程遠いかもしれませんが、
技術書好きの一人として登壇させていただいてとても楽しかったです。

テーブルに並べてた本で読んでないものもあるのでまた読みます。

ドメイン駆動設計読書会 第2章 コミュニケーションと言語の使い方

エリック・エヴァンスのドメイン駆動設計の読書会で理解したことをメモしていきます。今日は第2章です。

第2章 コミュニケーションと言語の使い方

ユビキタス言語：ドメインモデルが対象とするスコープ内で使用するドメインエキスパート、開発者間での共通言語
プロジェクトではモデルによるコミュニケーションのみでなくユビキタス言語による会話が不可欠である。
ユビキタス言語は使用中にひっかかりや違和感があれば変更されなければならず、それに伴いモデルも変更されるべきである。

声に出してモデリングする

ドメインモデルを改良するためには声に出してみるとよい。表現すべきことをより簡潔に言う方法を見つけ、その新しい考え方を図とコードに再び反映させること

1つのチームに1つの言語

ドメインエキスパートが抽象化したモデルを理解できないからといってドメインモデルから遮断したり、別のモデルを作成してはいけない。ドメインエキスパートがモデルを理解できない場合には、モデル側に何らかの問題がある。
ユビキタス言語を用いることにより、開発者間の会話やドメインエキスパート間の議論、そして、コードそのものでの表現がすべて、共有されたドメインモデルから得られた同一の言語に基づくようになる。

ドキュメントと図

UML図はオブジェクト間の関係性を表現するのには役立つが、オブジェクトの概念の定義については表現しきれない。また、実装の詳細はコードで表現されるべきである。モデルは図ではない。図はモデルについてコミュニケーションするためのツールである。

書かれた設計ドキュメント

ドキュメントはコードや会話でのコミュニケーションを補わなければならない。アジャイルやXPではコード自体を設計ドキュメントとして扱うが、「なぜそうするのか」という背景の部分までは表現できない。ドキュメントは活動の役に立たなければならず、最新の状態を保たなければならない（むしろその方法を知りたいんだけど、詳細なドキュメントについて指示するつもりはないと筆者は書いている）。
ドキュメントはプロジェクトの活動に取り込まれていなければならない。ユビキタス言語に耳を傾け、ドキュメントとの相互作用を観察することで、活動にドキュメントがプロジェクトの活動に取り込まれているかどうかを確認できる。

実行可能な基盤

コードが引き起こすふるまいこそが現実である。コードによって伝えられるメッセージができる限り正確であるためには、規律を守り、設計について特定の考え方をし、要件を書くのに使用されたユビキタス言語に基づいていなければならない。

説明のためのモデル

実装、設計、チーム内のコミュニケーションの根底にあるモデルは1つだけであるべきだが、説明のためにソフトウェア設計とは直接関係しないモデル（この文脈だと図と言ったほうが正確な気がする）を使用することは人々の理解を助ける。

ドメイン駆動設計読書会 第1章

ひょんなことからエリック・エヴァンスのドメイン駆動設計の読書会をすることになりました。

会話の中で理解したことをメモしていきます。今日は第1章です。

第1部 ドメインモデルを機能させる

• ドメイン：ユーザーの活動や関心についてプログラムを適用する対象領域
• ドメインモデル（モデル）：ドメインについての知識を抽象化したもの。特定の図ではなく、図で表された考え方そのものを指す。
• 言語：共通認識を共有するための記号・手段・取り決め。かな。
• エンティティ：データのかたまり

ドメインモデルの有用性

• モデルと設計の確信が相互に形成し合う
• チームメンバが使用する言語の基盤になる
• もっとも関心のある要素を区別する

ソフトウェアの核心

ドメインについて理解することで適切なソフトウェア開発を行うことができる。

第1章 知識をかみ砕く

PCB基盤の設計支援ツールを例に、モデルを作ることで共通言語を得、本当に関心のある事柄を抽出し、プロトタイピングを行い、イテレーションを回すこと＝知識をかみ砕くことで効果的なソフトウェア開発を行うことができることを説明

効果的なモデリングの要素

• モデルと実装を結びつける
• モデルに基づいて言語を洗練させる
• 知識豊富なモデルを開発する
• モデルを蒸留する
• ブレインストーミングと実験を行う

これにより知識をかみ砕く。

知識のかみ砕き

ドメインエキスパートと開発者チーム全員がモデルを噛み砕くことで、モデルにビジネスに関する深い知識が反映され、実装の助けになる。

継続的学習

継続的にドメインモデリングのスキル、技術的な知識、ドメインについて学習する。
初期の作業によって知識のかみ砕きというプロセスを発動させ、それによって以降の全作業を効率的に行う。

知識豊富な設計

これらのプロセスによって知識をかみ砕くことで、モデルを変化させ、実装をリファクタリングし、新しい知識をアプリケーションで使用することができるようになる。