QCon Tokyo 2016参加レポート

# はじめに
[QCon Tokyo 2016](http://www.qcontokyo.com/program.html)に行かせていただきました。
招待いただきありがとうございました。
個人的なまとめを、つらつら書いていきます。


## 基調講演１
エンジニアリングの物語り(ストーリーテリング)～人に語るに値するカルチャー
Engineering Storytelling - Culture Worth Talking About
[Pete Soderling 氏　Hakka Labs](http://qcontokyo.com/PeteSoderling_2016.html)
最高のエンジニアリングチームを作るにはどうすると良いのか?
* カルチャーは、いろいろな衝突を解決することに醸成されてきた。
* 文化を学びストーリーテリングを学ぶと、よりよいリーダーになることができる。
* ストーリーを語り文化を伝えると、インスピレーションを他の人に与えることができる。

良い文化とは、
* 自主性、自立性がある
例: Googleは、最小限のマネージャー、全体の20%は自由な時間
そうすることで、インスピレーションが生まれ、チームの繋がりも強くなった。
カルチャーを変えるなら、「Move fast with stable infra」: 迅速に作って壊す
* インパクトを与える
* オーナーシップを持つ
「自分の書いたコードに責任を持つ」
エンジニアがサービスの責任を持つということにすると、文化が変わった。
また、アーキテクチャの変更が文化の変化につながった。
* 常に学習し続ける
ペアプロはいいぞ。


## 基調講演２
ポスト・ムーア法則時代のコンピューティング
[佐藤一郎 氏　 国立情報学研究所 アーキテクチャ科学研究系 教授](http://qcontokyo.com/IchiroSatoh_2016.html)
ITは、ムーアの法則に依存している。
現代は、ITに依存しているから、ムーアの法則は現代に影響する。
ムーアの法則が綻びると、ITによる生産性課題の解決ができなくなるってことが懸念される。
コンピュータ性能が向上しないということは、課題解決が向上しないということ。
電力的な限界と経済的な限界がきている。

最新のコンピュータに変えても性能向上しないと気付くと、ソフトを変えない
システムを更新しなくなる。
現状のシステムをなるべく長く使うことに関心事が変わる。

世界には、2種類のコンピュータしかない。
壊れたコンピュータと、
いずれ、壊れるコンピュータ

## 基調講演３
日本の情報システムの未来革新に向けて
～日本の金融業界におけるテクノロジーの可能性と今後の情報システム部門の進むべき道 
[浦川 伸一 氏 損害保険ジャパン日本興亜株式会社　取締役　常務執行役員](http://qcontokyo.com/ShinichiUrakawa_2016.html)
http://qiita.com/y_q1m/items/d818786d10f6df1d2b69

## マイクロサービス・アーキテクチャのパターンとベストプラクティス
Patterns & Practices of Microservices
[Wesley Reisz 氏 C4Media社](http://qcontokyo.com/WesleyReisz_2016.html)
* CQRS
* EventSourcing
* サーキットブレーカー

## DDDとマイクロサービスの現実と可能性
###(1)現場からの実践報告 
[上坂 貴志 氏 株式会社ネクストスケープ](http://qcontokyo.com/TakashiUesaka_2016.html) 
マイクロサービスのパターン?非同期処理のパターン！
クラウドデザインパターンの本に解説がある。
モデリングとER図は違う！！
間にはレイヤーがある。

DDD導入を成功させるには、
* ユビキタス言語を定義する。
* モデルをドメインレイヤーに閉じ込める。

クラウドの良さを生かすなら、非同期処理。


#### なぜDDDなのか
DDDは設計手法だけではない。
開発プロセス全部まとめてやるから意味があります。
ユーザーと開発側と差が生じる。理油は、お互いが暗黙的な一般常識に当てはめてしまうから。
コンテキストが違えば、同じ言葉でも違う意味を持つので、ユビキタス言語として定義していく必要がある。
モデル駆動は、お客様の前でやるからこそ、DDDは威力を発揮する。
分析用と実装用のモデル２つ用意することもあるけれど、意味がない。

### (3)DDD&モデリング導入のコツ
[増田 亨 氏 ギルドワークス株式会社 ](http://qcontokyo.com/ToruMasuda_2016.html)
ドメイン駆動設計の効果
* 役に立つソフトウェアを
* 確実に
* 効率的に

ドメイン駆動設計の基本の活動
* 知識をかみ砕く
* 言葉を活用する
* モデルと実装を一致させる

ドメインをかみ砕く = ドメインのオブジェクトモデルを作っていくこと

ドメイン駆動設計を支える技術
* オブジェクト指向
データクラス + 機能クラス　→　ドメインオブジェクトの世界へ
* インクリメンタルな設計
具体的にチームの習慣にする

ドメイン駆動設計の2つのブレークポイント
* オブジェクト指向
* インクリメンタルな設計

オブジェクト指向のおすすめ本
* オブジェクト指向エクササイズ
9つのルールがポイント
1. 1つのメソッドでインデントは1段階
2. else句はつかわない
3. すべてのプリミティブ型と文字列をラップする
4. 一行につきドットは1つまで
5. 名前を省略しない
6. すべてのエンティティを小さくする
7. 一つのクラスのインスタンス変数は2つまで
8. ファーストクラスコレクションを使う
9. getter, setter, プロパティを使わない

* 関数に名前をつけることは、何のためにそのコードを書いているのか
目的を強要することになるので、重要である。

* データとロジックを凝集させる[3.6.7.8.9]

* 複数の関心ごとを持たない[1.2.4.7]

関数に名前をつけることは、何のためにそのコードを書いているのか
目的を強要することになるので、重要である。

#### 設計の改善
* 名前の変更
* メソッドの抽出
* クラスの抽出
* メソッドの移動/フィールドの移動

#### インクリメンタルな設計
できるだけ早くコードを書き始める。
動いたコードをもとに改善をする。

コードに書いて動かしてみると学びが多いし、その学びをコードに反映できる。
そういう設計の方が効率が良い。


##### 体制とやり方
コードを書く人間が要件のヒアリングと分析をする
それができる人間を育てる。

##### どんな状況でも改善できる！！


### (2)DDD実践ベストプラクティス　
[加藤 潤一 氏 ChatWork株式会社](http://qcontokyo.com/JunichiKato_2016.html)
[スライドはこちら](https://speakerdeck.com/j5ik2o/dddshi-jian-besuto-purakuteisu-domeinibentotomaikurosabisutozu-zhi-falseguan-xi)
ドメインイベントとマイクロサービスの関係

#### CQRSとは
* コマンド・クエリ分離原則

あらゆるメドッドは、アクションを実行するコマンドか、呼び出し元にデータを返すクエリかのいずれかであって、両方あってはならない。
これは、質問をすることで回答を変化させてはならないということだ。

#### ドメインイベントが主役になるイベントソーシング
ドメインモデルをデータとして格納するのではなく、発生するドメインイベントを全て永続化する。

DDD + CQRS
設計がシンプルになる。

### パネルディスカッション ~DDDの課題は何か、今後どうなる?~
##### Q1 ユビキタス言語をモデリングし、いかにドメインエキスパートと共有しているか?
増田さん: エヴァンスが書いているように、ドメインエキスパートと開発者が毎日会話するのは難しい。
しかし、開発者同士の中での会話で、ドメインエキスパートが定義した言葉が出てきていなかったり、
間違って使われていたりすると、おかしいので確認を取る。
杉山さん: DDDをやっていると、言葉の意味に敏感になる。

##### Q2 コンテキストマップ戦略の9パターン
1. パートナーシップ
2. 共有カーネル
3. 腐敗防止層
4. 顧客/供給者
5. 順応者
6. 公開ホストサービス
7. 別々の道
8. 巨大な泥団子
9. 公表された言語

##### Q3 DDDはマイクロサービスの設計手法として有効なのか?
 → コミュニケーションに重きを置いている。考え方では、適応しやすいという位置付けだと思う。

##### Q4 コンテキスト・集約と整合性との戦略わ?

##### Q5 CQRSの3タイプ
CとQの間のリレーションを失ってはいけない。
ユースケースから考えていくと、紐付けが取れていくが、
分けることを先行してしまうと、うまくいかないこともある。

### サーバーレス・アーキテクチャ
[伊藤 直也 氏 株式会社 一休 執行役員 CTO](http://qcontokyo.com/NaoyaIto_2016.html)
[スライドはこちら](https://speakerdeck.com/naoya/serverless-architecture)
常駐プロセス的な意味で、サーバーレスのお話。
function as a service
具体例はAWS Lambda
` Req - S3 - kinesis - SES - Dynamo `

Lambdaいっぱい作っていくと、マイクロサービスになる。
コレオグラフィーは疎結合で柔軟性がある。
どこかで失敗したら、戻すのではなくて、捨てて、新しく作り直す。
サーバーレスアーキテクチャの面白いところ、
自然と分散志向になっていって、テスタビリティが高くなっていく。
ただ、開発コストは下がらない。
あと、デバッグが大変。

### DevOps導入＆実践の落とし穴　- Disciplined DevOpsに見る体系的アプローチ
[藤井 智弘 氏 日本ヒューレット・パッカード株式会社](http://qcontokyo.com/TomohiroFujii_2016.html)
DevOpsの定義は難しい。

ディシプリンド・アジャイル・デリバリー（DAD）の基礎
・スクラムの拡張
　・スクラムはシステム構築にフォーカスが偏っている
・利害関係者との合意形成
　・例えば法的問題が関わるなら法務と合意が必要
　・関係者全員との議論もフェーズに含める
・ゴール駆動

## 終わりに
speekerの皆様、ありがとうございました。
長い１日でした。
個人的には、基調講演2とDDDのセッションとサーバーレス・アーキテクチャが興味深い内容でした。