DDD Alliance! 3週連続DDD 第3週に行ってきたよメモ（最終回）

今週は第4部。
最終回です。

増田さん、DDD Allianceのみなさん、3週連続ありがとうございました。

今回は増田さんが実際に仕事でやってる内容の話を交えてくれました。
毎度の事ながら自分メモなのでキレイに体系的に情報がまとまってるわけじゃないのであしからず。

戦略的な取り組みの事例

• HR Solutions
  • 人事採用ドメイン
  • 採用・雇用というのは企業戦略に係わってくる
  • 人事担当者の人によって大きく変わってくる
  • 社長がすごい営業してくるのでシステムが追いつかない
  • 次から次へと要望が出てくるのでしなやかな設計でやっている
  • （しなやかにやらないとついて行けないんだろうなあ…）
  • システム作りと運用が超大変
  • 経営のスピードがクソ速い
• SBヒューマンキャピタル
  • モデルの整合性の挑戦
  • 若手主体だったので個別の課題解決に忙殺されガチ
  • 現場レベルで取り組み意識が向上したことからDDD
• BIGLOBE
  • DDDで太陽系戦略に取組中
  • 壮大な取り組み
  • 一歩一歩前進中

戦略的に取り組む

色々障害は多いけど、何故取り組むのか？

よりよいものを作りたいという願望とかそういうのに係わる一員でいたい
ものづくり屋の本能

誰がやるのか？

現場。
アーキテクチャチームとかが基盤をっていうのと真逆。
現場の人がやるのが一番効果的。
コード書いてる人が知識を得て戦略的に取り組む。

たしかに自分はアーキテクチャチームだけど、これを開発チームに落として一緒にやっていこうってのが大事だと思う。

戦略を「コード」で表現する

基本が大切

戦略的に取り組む場合こそ基本が大切

これが増田さんからの一番のメッセージ。
基本から離れたらアカン。

4部の1つをすぽんと取り出してやったとして何か良いことがあるかというとないだろう。
基本が大事。

選抜されたアーキテクチャチームがやることじゃない。
たくさんの関係者がいますよ。
すぐに戦略的に変われるとは限らない。
時間がかかる話だ。

オブジェクト指向

変更容易性
メッセージングはモジュラープログラミングをつなぐもの

手続き型だろうが、関数型だろうが、ドメイン層で関心事をコードに落とした場合、どのパラダイムでも似たようなコードになるだろう。

メッセージングとモジュール化によって組み替えやすくする。
人の仕組みだってそうだ。
たしかに。

ソフトウェアの開発スタイル

ソフトウェア開発は変更との闘いの歴史

• 変更は管理するものだ（予測型）
  • 理想があって変わらないものだ
• 変更を受け入れる（反復・漸進型）
  • 変更はあるから反復する中で受け入れよう
• 変化を目指す（適応型）
  • XPはもっと違うことを言っているんじゃないか
  • 変化することを目指そうと言うことを言ってるんじゃないか
  • 哲学

ソフトウェアは変化を起こすためにある
DDDの根底にも流れている哲学

変化を目指す開発チーム

何が起きるか

• コミュニケーション
• シンプルになる
• フィードバックが発生する
• 勇気
  • 今はその時期ではないなどの忍耐力
  • 前回のブレークスルーからの、という感じかな
• お互いに関心を持ちリスペクトする
  • 相手の関心事に興味を持つ
  • どう言う思いを持っているかを理解しようとする姿勢

戦略的に取り組む

第1部の三原則
広い範囲で、長期的に、たくさんの人と取り組もう

戦略的であってもコードに落とす。
コードで表現するから戦略的に取り組むことができる。

事業の背景とかにまで視野を広げることは大変だが方向性としてはこういうこと。

外部との連携もひっくるめてようやくする。
モデルとしてシンプルでわかりやすくする。

無視して良いものは何かを要約できる力が必要。
無視して良いものは何かを実験してみる力、勇気。
高いレベルが求められる。

第3部を戦略的に実践する

小さなアプリケーションであれば比較的簡単。
しなやかに設計する、深いモデル。

いろいろなコンテキストが絡み合ってくると難しい。
関係者で言葉を使って議論するというのが大切

概念を掘り出す

第14章モデルの整合性を維持する

境界づけられたコンテキスト

大きな部品を特定する

開発チームが違ってたら同じも出るって事はない
1つのモデルであろうという候補。

運用チーム

概念は別々の人の頭の中でバラバラに進化し始めることに注意する。
1週間後に同じように進化するとは限らない。
10人いたらみんな違う可能性

デプロイして動いてるからと言って共有できているとは限らない。
しゃべることが重要。

• まずは単独のコンテキストの一貫性を保つ。
• そこから複数のコンテキストに広げていく

コンテキストマップ

データの整合性をどうするか、通信をどうするかを考えるという話でない。
それぞれの違いを見つけて、どう関係づけるのか。
これを分かるようにするのがコンテキストマップ。

ビッグローブでは30人とか集まって各チームのリーダーとかでコンテキストマップを作った。
理想論を書くことじゃない。
現実がどうなってるかを書く。

関係者で作ると気づきが増えてくる。

うちでもこれ作りたくなってきた。
そういうことか。

別々の道になるって事はコミュニケーションが成り立っていなかったと言うこと。

14章の要点

• 現実を直視する
  • ある種の美しさ
  • 色んな人が係わって妥協やらなにやらしながら作り上げたものだからこそ美しい
• コミュニケーションが大事
• 統合することは一般論的にはいいことだけど現実は色々コストとかあるよね

密接な関係を実現する

• 共同経営
  • 何かあったらちゃんという
• 共有カーネル
  • 複数チームで共同開発
• これらの短期的にどうなのか、長期的にどうなのかを意思決定する
• 開発チームがその意思決定をすることが力になる

明確な関係を打ち立てる

密接だといろいろとコストとかがでかくなりすぎることがある

• 公開ホストサービス
  • MSAとかもここの文脈に入るのでは
  • 使う側、提供する側がコミュニケーションする
• 公表された言語
  • 例：人事のデータ交換のためのフォーマット
  • 業界横断的
  • 一時期プチブームになりかけたけどあんま使われてない
  • みんなで共有できなかった、コミュニケーションが不足したため流行らなかった
  • それぞれの業界のXMLの標準化
  • 一度はそういうのがあるなら目を通すと勉強になるよ

独立した別のチーム

コミュニケーションできない、していない
別々のチームになっているというのは大体「別々の道」

順応者→とりあえず合わせます。

腐敗防止層→コンバートする

チーム間の対等な関係ではない。
現実ではよくある話。

関係者でこれらをどうしていくかを話す。

コンテキスト感の関係の意思決定

戦略を選択するときの考え所

• 現実の直視
• トレードオフ
• 実践的な判断

熟読すべし！！！
関係者で議論すべし！！！

ここに体験談など詰まってる！

変換（関係を変えていく）

• 別々の道→共有カーネル
• 共有カーネル→継続的な統合
• レガシーを廃止していく
• 公開ホストサービス→公表された言語

自分たちの企業でやっていたことをAPIとして公開していく
AWSとかがそんな感じ。

実践的な判断はどこをキーにするのかが書いてある。

まとめ

• 1つのコンテキスト内部のモデルの一貫性を維持する
• 現実のコンテキストマップを作る
• 関係者で活発に議論する
• 意思決定を必ずコードで表現する

第15章蒸留

• ドメインビジョン声明文
• 協調されたコア
• 凝集されたメカニズム
• 抽象化されたコア

コアドメイン＝選択と集中

要約中の要約
周りにおぼれないように芯を捉える。
さらに高度な要約力が必要。

どうやって探すのか？

塊を抽出する

汎用サブドメイン

• 注文
• 認証
• とかとか

かたまりの意図を明確にする
関係を言葉で表現する

コアドメインの具体化4つの段階

• ドメインビジョン声明文
  • 中心の関心事は何か、言葉を使って表現する
  • 費用対効果が高い
  • キレイにできなくても議論することで得るものが多い
  • 語尾を曖昧にしない
  • 形式的に言い切る、きちんと適度に文を切る
  • あれ、これ、それ→なに？
  • カタカナ言葉は人によって差があるから使わないようにする
• 強調されたコア
  • 実装は変更しない
  • 要点をマーキングして終わりではダメ
  • 重要な関係を 言葉 で表現する
• 隔離されたコア
  • 深いモデルをコードに反映
  • ここまでできればかなりレベルの高い蒸留になる
• 抽象化されたコア
  • 深いモデルの探求の帰結
  • はっきりとこれが抽象化されたコアだ！ってのはできたことはない
  • まずは蒸留の初歩段階から取り組む

まとめ

中核の関心事をコードを書く人間が理解していれば非常に強力な武器になる。
蒸留すればするほど安全になる。
抽象化していく。

とはいえ、一朝一夕にできるわけじゃない。
チームで、大勢で長期的に言葉を使って実践する。

第16章大規模な構造

主題：森を見る力

大きな所から俯瞰して理解する

少しずつ成長・改善していく

メタファー→分かったつもりになるから気をつける。
だれでも同じ言い回しになることが必須。

責務のレイヤに注目することでキレイに分けられるようになるよという話。
絶対的にこうしろという話ではない。

知識レベル

着脱可能なコンポーネントフレームワーク
ここだめ熟成している間に環境が変わってしまうから結果としてそうなってるくらいのパターン

ふさわしい構造へのリファクタリング

ミニマリズム 一度に大きく取り組まない

大規模なことを考える場合は16章を読み直すと良いよ。
ヒントになるものが落ちてる。

第17章戦略をまとめ上げる

読み直してください！！！

現状を正しく把握する！

技術的な関心事しかないチームだったらコンテキストマップなんて作れない。
チェックリストとして使って欲しい。

開発チーム＝ドメイン層の開発してるチーム
アーキテクチャチームがやるのなら、それは開発チームへの貢献をマインドセットとしたチームでやるべきだ。

やりながら成長してけばいい。
それをどうするか考えれば良い。

3週連続DDDのまとめ

DDDとは？

厳しい現実の中でソフトウェア設計を習得しようと奮闘してきた技術者の物語。
成功も失敗もあるんだよ。

増田さんの抱えている問題に刺さってくるものがある。

「実践的な設計」の勉強を続けよう