はじめに
QCon Tokyo 2016に行かせていただきました。
招待いただきありがとうございました。
個人的なまとめを、つらつら書いていきます。
基調講演１
エンジニアリングの物語り(ストーリーテリング)～人に語るに値するカルチャー
Engineering Storytelling - Culture Worth Talking About
Pete Soderling 氏 Hakka Labs
最高のエンジニアリングチームを作るにはどうすると良いのか?
* カルチャーは、いろいろな衝突を解決することに醸成されてきた。
* 文化を学びストーリーテリングを学ぶと、よりよいリーダーになることができる。
* ストーリーを語り文化を伝えると、インスピレーションを他の人に与えることができる。
良い文化とは、
* 自主性、自立性がある
例: Googleは、最小限のマネージャー、全体の20%は自由な時間
そうすることで、インスピレーションが生まれ、チームの繋がりも強くなった。
カルチャーを変えるなら、「Move fast with stable infra」: 迅速に作って壊す
* インパクトを与える
* オーナーシップを持つ
「自分の書いたコードに責任を持つ」
エンジニアがサービスの責任を持つということにすると、文化が変わった。
また、アーキテクチャの変更が文化の変化につながった。
* 常に学習し続ける
ペアプロはいいぞ。
基調講演２
ポスト・ムーア法則時代のコンピューティング
佐藤一郎 氏 国立情報学研究所 アーキテクチャ科学研究系 教授
ITは、ムーアの法則に依存している。
現代は、ITに依存しているから、ムーアの法則は現代に影響する。
ムーアの法則が綻びると、ITによる生産性課題の解決ができなくなるってことが懸念される。
コンピュータ性能が向上しないということは、課題解決が向上しないということ。
電力的な限界と経済的な限界がきている。
最新のコンピュータに変えても性能向上しないと気付くと、ソフトを変えない
システムを更新しなくなる。
現状のシステムをなるべく長く使うことに関心事が変わる。
世界には、2種類のコンピュータしかない。
壊れたコンピュータと、
いずれ、壊れるコンピュータ
基調講演３
日本の情報システムの未来革新に向けて
～日本の金融業界におけるテクノロジーの可能性と今後の情報システム部門の進むべき道
浦川 伸一 氏 損害保険ジャパン日本興亜株式会社 取締役 常務執行役員
http://qiita.com/y_q1m/items/d818786d10f6df1d2b69
マイクロサービス・アーキテクチャのパターンとベストプラクティス
Patterns & Practices of Microservices
Wesley Reisz 氏 C4Media社
* CQRS
* EventSourcing
* サーキットブレーカー
DDDとマイクロサービスの現実と可能性
(1)現場からの実践報告
上坂 貴志 氏 株式会社ネクストスケープ
マイクロサービスのパターン?非同期処理のパターン！
クラウドデザインパターンの本に解説がある。
モデリングとER図は違う！！
間にはレイヤーがある。
DDD導入を成功させるには、
* ユビキタス言語を定義する。
* モデルをドメインレイヤーに閉じ込める。
クラウドの良さを生かすなら、非同期処理。
なぜDDDなのか
DDDは設計手法だけではない。
開発プロセス全部まとめてやるから意味があります。
ユーザーと開発側と差が生じる。理油は、お互いが暗黙的な一般常識に当てはめてしまうから。
コンテキストが違えば、同じ言葉でも違う意味を持つので、ユビキタス言語として定義していく必要がある。
モデル駆動は、お客様の前でやるからこそ、DDDは威力を発揮する。
分析用と実装用のモデル２つ用意することもあるけれど、意味がない。
(3)DDD&モデリング導入のコツ
増田 亨 氏 ギルドワークス株式会社
ドメイン駆動設計の効果
* 役に立つソフトウェアを
* 確実に
* 効率的に
ドメイン駆動設計の基本の活動
* 知識をかみ砕く
* 言葉を活用する
* モデルと実装を一致させる
ドメインをかみ砕く = ドメインのオブジェクトモデルを作っていくこと
ドメイン駆動設計を支える技術
* オブジェクト指向
データクラス + 機能クラス → ドメインオブジェクトの世界へ
* インクリメンタルな設計
具体的にチームの習慣にする
ドメイン駆動設計の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株式会社
スライドはこちら
ドメインイベントとマイクロサービスの関係
CQRSとは
- コマンド・クエリ分離原則
あらゆるメドッドは、アクションを実行するコマンドか、呼び出し元にデータを返すクエリかのいずれかであって、両方あってはならない。
これは、質問をすることで回答を変化させてはならないということだ。
ドメインイベントが主役になるイベントソーシング
ドメインモデルをデータとして格納するのではなく、発生するドメインイベントを全て永続化する。
DDD + CQRS
設計がシンプルになる。
パネルディスカッション ~DDDの課題は何か、今後どうなる?~
Q1 ユビキタス言語をモデリングし、いかにドメインエキスパートと共有しているか?
増田さん: エヴァンスが書いているように、ドメインエキスパートと開発者が毎日会話するのは難しい。
しかし、開発者同士の中での会話で、ドメインエキスパートが定義した言葉が出てきていなかったり、
間違って使われていたりすると、おかしいので確認を取る。
杉山さん: DDDをやっていると、言葉の意味に敏感になる。
Q2 コンテキストマップ戦略の9パターン
- パートナーシップ
- 共有カーネル
- 腐敗防止層
- 顧客/供給者
- 順応者
- 公開ホストサービス
- 別々の道
- 巨大な泥団子
- 公表された言語
Q3 DDDはマイクロサービスの設計手法として有効なのか?
→ コミュニケーションに重きを置いている。考え方では、適応しやすいという位置付けだと思う。
Q4 コンテキスト・集約と整合性との戦略わ?
Q5 CQRSの3タイプ
CとQの間のリレーションを失ってはいけない。
ユースケースから考えていくと、紐付けが取れていくが、
分けることを先行してしまうと、うまくいかないこともある。
サーバーレス・アーキテクチャ
伊藤 直也 氏 株式会社 一休 執行役員 CTO
スライドはこちら
常駐プロセス的な意味で、サーバーレスのお話。
function as a service
具体例はAWS Lambda
Req - S3 - kinesis - SES - Dynamo
Lambdaいっぱい作っていくと、マイクロサービスになる。
コレオグラフィーは疎結合で柔軟性がある。
どこかで失敗したら、戻すのではなくて、捨てて、新しく作り直す。
サーバーレスアーキテクチャの面白いところ、
自然と分散志向になっていって、テスタビリティが高くなっていく。
ただ、開発コストは下がらない。
あと、デバッグが大変。
DevOps導入＆実践の落とし穴 - Disciplined DevOpsに見る体系的アプローチ
藤井 智弘 氏 日本ヒューレット・パッカード株式会社
DevOpsの定義は難しい。
ディシプリンド・アジャイル・デリバリー（DAD）の基礎
・スクラムの拡張
・スクラムはシステム構築にフォーカスが偏っている
・利害関係者との合意形成
・例えば法的問題が関わるなら法務と合意が必要
・関係者全員との議論もフェーズに含める
・ゴール駆動
終わりに
speekerの皆様、ありがとうございました。
長い１日でした。
個人的には、基調講演2とDDDのセッションとサーバーレス・アーキテクチャが興味深い内容でした。