第4部 戦略的設計
14章 モデルの整合性を維持する
以下は、モデルの整合性を維持するためのテクニック？的な感じの説明なのかなたぶん
- 継続的な統合
- コンテキストマップ
- 共有カーネル
- 顧客・供給者の開発チーム
継続的な統合
継続的な統合 とは(雑)
チームみんなでちゃんと話し合って共通認識を作った上で、コピペコードとか書かないでちゃんと実装しよ
継続的な統合 あるある
- 複数人とかで開発してると同じ機能が重複して実装されたりするよね
- なんか既存の機能よくわからないからコピペして新しい機能実装しよ
→ アカン！
継続的な統合 やる意味
継続的に実装(コード)とか概念(モデル)とか統合していかないとモデルの正当性や一貫性が保てないよ！
継続的な統合 とは
継続的な統合とは、そのコンテキスト内で行われるすべての作業について、頻繁にマージして一貫性を保つことにより、分派が見られたときにすぐに発見して修正できるようにすることを意味する
エリック・エヴァンスのドメイン駆動設計 p350
継続的な統合 具体的話
- XP(エクストリーム・プログラミング)おすすめ (アジャイル的な)
- 1日に1回コードをマージする(できるだけ頻繁に統合したほうがいい)
- 自動化テストあったほうがいいよ
- ユビキタス言語の執拗な鍛錬(概念は別々の人々の頭の中で進化していくよ)
- 仕事を必要以上に大きくしないこと(境界づけられたコンテキスト内での話だよ)
コンテキストマップ
コンテキストマップ とは(雑)
境界づけられたコンテキストのマップ(図)
→ コンテキストを意識したモデル(共通概念)の図的なもの
コンテキストマップ メリット
- チーム全員のモデルを共通化できる
- 説明があいまいにならないですむ
- あいまいな箇所がわかる
コンテキストマップ 作り方
- ドキュメントじゃなくてもいいけどドキュメントにしたほうがいいと思う(チームがわかっていればなんでもいい)
- それぞれの境界づけられたコンテキストに名前(ユビキタス言語)をつける
- PJにあるモデルのコンテキスト全てに関する全体的な視点
- モデル同士の接点も書く
- わかりにくいところには概略を述べ、強調すべきところは強調して書く
コンテキストマップ 注意点
- 常にありのままの現状を書く(こうなってほしいとか、今後こういう修正を加えるとかは書かない)
- コンテキストマップにしにくかったら修正したほうがいい
- 修正したほうがいいなーと思ったらマップにはドラゴンを書いて、一旦おいておく
- 最優先は明確なコンテキストマップを一旦書くこと
- 境界づけられたコンテキストには名前をつける(そした、その名前をユビキタス言語にする)
- チーム全員がすべての境界を認識し、理解する。また、そのコミュニケーションを惜しまない
コンテキストマップ まとめ
「ジョージのチームが担当しているものが変更されているから、それと通信するこちら側の部分も変更しなければならない」
↓
「運送ネットワークモデルが変更されているから、予約コンテキスト向けの変換サービスを変更する必要がある」
エリック・エヴァンスのドメイン駆動設計 p361
共有カーネル
共有カーネル とは(雑)
あっちのコンテキストからも使いたいし、こっちのコンテキストからも使いたいなーって感じだったら、そこは共通部分にしてしまってもええで！
例：同じAPIを使用している複数アプリのAPI側とか
※この例は間違っている可能性があります
共有カーネル 注意点
- 共有カーネルにするかどうかは慎重に検討してね
- 他の設計より簡単に変更できないよ
- 他の部分が1日に1回マージするぐらいの頻度だったら、共有カーネルは週1ぐらいのイメージ
- 変更する場合はそれぞれのコンテキストの関係者の合意が必要(つまりめんどくさい)
- 両方のテストを通過しないとリリースできない
顧客・供給者の開発チーム
顧客・供給者の開発チーム とは(雑)
上流のシステム(API)と下流のシステム(アプリ)の開発をするときは、上流=供給者、下流＝顧客としてPJを進めていくとうまくいくんじゃないかな
顧客・供給者の開発チーム とは(雑)
まぁ、お互いのスタンス(顧客・供給者)とルールを決めておくとスムーズに行くよって話
顧客・供給者の開発チーム 注意点
- 供給者は顧客の要望を尊重する(顧客の要望が基本的には最優先)
- 下流の代表は上流のMTGに参加する(機能の提供の約束とスケジュールを全員で理解する)
- 下流は上流に対する要望を自動テスト化する(下流と上流が協力してテストを作成する)
- 上流はこのテストを毎回実行し、確実に通過するものを納品する
- テストを修正する場合はお互いに話し合う(もちろん実装も変わるしね)
- 利用が単方向である