2018/1/10 DCI Tokyo 1 参加レポート（memo）
注：だいぶ苦労して整理しましたが、抽象的でややこしい内容なのは、そういうものとしてご容赦ください。
カンファレンス内容
セッションテーマ
- 書籍「Lean Architecture」の著者James CoplienによるLean Architectureの解説
ハッシュタグ
#dcitokyo
以下、セッション内容メモ
前提①：FormとStructureの違いについて。
Formとは抽象的なものであり、Structureはもっと具体的なもの。
現実のもので例えてみよう。
【椅子の例】
- ここに椅子がある。椅子とはFormである。
- あそこにも違う形の別の椅子がある。Formは同じ。しかし形が違うので、Structureは違う。
- こちらにあるソファはどうか。これは椅子とは違うのでFormも異なる。
【ボトルの例】
- ここにガラスのボトルがある。
- これを作るときは型を作り、そこにガラスを流し込んで作っただろう。
- 同じ型に溶かしたチョコレートを入れたり、ゴールドを入れても物を作ることができる。
- これは、同じFormで別のStructureを作るという意味になる。
【椅子とソファ】
- 椅子とソファはなぜ違うと認識できるのだろうか。
- 認識した後に説明はつけられるだろう。例えば、椅子はソファに比べてカチッとしているとか。
- つまり、説明がなくても、頭ではもともと理解していることである。
【前提①をシステム開発に照らし合わせると】
- 設計のときは単にListを使う、としていたとする。
- 実装のときに初めて、そのListの中の値がIndexで並んでいるのか、シンボリックネームで並んでいるのかなどを意識することがある。
- 設計のときはその辺を気にしない。それがFormである。
- 実装のときに気にした要素、それがStructureである。
前提②：FormとFunction
【椅子と段差】
- Formは違うけどFunctionが同じものがある。
- 例えばここにある段差。ここに腰かけることができる。
- じゃあこれは椅子か？違う。
- これが、Formは違うけどFunctionが同じであるということ。
【前提②をシステム開発に照らし合わせると】
前提①と②に関する警鐘
【最初は頭を空に】
- システム開発において、最初からプログラム言語やオブジェクト指向を意識した設計をすべきではない。
- そういう要素に対しては頭を空にして考えるべき。全てを椅子であるとして見てはならない。
- 設計を進める上で、同じ部分を見出し、Commonality（共通性）を設定していくことが大事。
【JavaやC++の問題】
- Structure（構造）のCommonality、Behavior（動作）のCommonality、どちらも存在する。
- JavaやC++はどちらも同じように実装に落とし込める。
- それは言語仕様としてよくないことだと思う。
※そもそもC++はオブジェクト指向言語ではなくマルチパラダイムプログラミング言語として作られている。その点は誤解すべきでない
【銀行の送金トランザクションを例にした説明】
A～Cのステップで説明。
- 送金トランザクションで使われるオブジェクト、ひとつひとつにIDを持っている。
- (A)このIDを印刷してみよう。
- ID（数値）の羅列が続くだろう（注：写真、見えますでしょうか。ランダムな数値の羅列）
- これでひとつひとつのオブジェクトが何をしているか、読みとれる人はいる？わたしにはわからない。
- (B)じゃあ、オブジェクトIDのかわりに、クラス名を印刷するものとしてみよう。
- 少しパターンが見えてきた。でもまだ完ぺきではない。
- (C)それでは、Roleの名前を印刷してみよう。
- これなら、その処理が何をしているかが見えた。
- これがこのFunctionのFormである。
- FunctionもFormを持っており、そしてそれはRoleの中にあるのだ。
【Javaの問題】
- 例えばJavaには多態性というものがある。それを用いると強力なプログラムをかけるが、これはどうやって理解し、テストできるのだ。
- こんなのはGoTo文と同じようなもの。
- こういうのがあるから人間が理解するのが大変になるのである。
注：つまり、BehaviorのCommonalityをそのまま実装に落とし込めてしまう悪しき例として話しているのだと思われる
【DCIとは】
- FunctionのForm、つまりRoleをプログラミング言語がネイティブにサポートする。そんな言語がDCIである（今はまだないけど、想像してほしい）。
【送金トランザクションの例をまとめてみる】
以下、自分なりの整理。
- つまり、前提②で書いたように、Behavior（動作）においては、振る舞いは同じだけどアイデンティティが違う実装が存在しうる。
- ではそのBehavior（動作）のアイデンティティとは何かというと、Role（＝FunctionにとってのForm）であると。
- そしてそのRoleを定義することが今のプログラミング言語はできない。
- それにより、段差を椅子として使っている（アイデンティティが違うのに、振る舞いが同じだから共通化している）ような処理が生みだされてしまうという問題がある。
- Roleを定義できればその問題がプログラミング言語の中でも解消できる（設計時には言語化しなくても誰もが知っている「椅子とは何か」の定義が、実装の中でも表現できる）。
- それがDCIだ。
という話だと理解。
※以降、第二部含め非常に良い話が続いたものの、
これ以上はうまくまとめられないので、ここで〆ます。
所感
- 本編はほぼ英語で、かつ抽象的・難解な内容であったため、理解に苦労したものの、率直に言ってめっちゃくちゃ面白かったです。
- 勉強会は、実際の製品に関する説明や、実装などに関する話もよいのですが、こういう理論に関する話が一番好きだなと実感しました。
- 多態性を使いまくったソースを追いにくいのは自分の能力が低いからと思ってしまいがちですが、ここまで思い切り Disrespect してもらえると大変心強いです 笑
- 書籍 Lean Architecture の和訳がないのが残念でなりません。出たら朝まで読み続けるであろう自信がついたくらい、強い興味がわきました。（英文で読めるほどの自信はないけど...）
現場は30分も延長するほどの大盛り上がり。
大変エキサイトできる貴重な勉強会でした。
運営、登壇者の方々ありがとうございました。
追記（2018/2/7）
公式のサマリ記事出ました。
当ブログのレポートにも触れて下さっています！
（後半の「今回のセッションの参加ブログ」のリンク部分）
PHP Mentors -> DCI Tokyo 1 - Lean Architecture by James Coplien - が開催されました（前編）
