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

[im-higashi]

コンテキストマップ

• コンテキストを明確にして境界をしっかり認識すること
• 詳細を滲み出させることを防止できる
  • 滲み出すものが多いと統合の負荷が高まる
• マップを作る段階で相手を正しく認識することで、相手を指すユビキタス言語ができる
• ≒サブシステム名ではなく

サブシステムを利用するときの名前なのかな

• コンテキストの境界で行うテスト
  • FWなどの安定したものではなく他のコンテキストへの依存はリスクが高い
    • リスクヘッジととしてテストは有用
• コンテキストマップを構成しているドキュメント化する
  1. 境界づけられたコンテキストには名前をつける
  2. 全員がその境界を認識できること

共有カーネル

• インフラストラクチャなどの共有だけでなく、ドメインモデルを共有する
  • 複数チームで同じようなドメインをそれぞれにもって個々に変更すると変換層がコストになる
    • であれば共有して、お互い頻度を落として統合することにメリットがあるのでは
  • 実装ツールが違う場合にこの手法を取るのは困難

共有カーネルは社内で導入されている箇所やこれからすべき部分はあるだろうか

顧客／供給者の開発チーム

• 上流、下流チームとして捉えるとそれぞれの利害相反が発生しがち
  • XPでのイテレーションプランニング
    • 下流チームを顧客ととらえて上流チーム側の作業を規定する

  スクラムに捉えるとプロダクトオーナーではなくステークホルダーと考えるべきか？
  

  • 上流チームは下流チーム（顧客）ｈのIFをテストに追加することで互換性を保ちつつ自身の変更容易性を担保できる
• 下流チームにとっては、顧客として要求を出すことで隷属関係ではなく正しい関係となる
• 上流チームは下流を壊さないことをテストで担保しつつ自身の変更容易性を担保する
  • 下流チームを顧客としてとらる動機付けが必要
• チーム内と同じく、顧客／供給者の開発チームでもHRT原則が基本なのでは

HRT原則：謙虚(Humility),尊敬(Respect),信頼(Trust)をベースとしたgooglでのチームビルディングの考え

順応者

• 上流チームに顧客として扱ってもらえない場合やそもそも要求できない場合の選択肢
  • 上流の機能を一切使用しない
    • 別々の道（次回）
  • 上流への依存は価値が高い
    • その設計が扱うのに困難（ぎこちない抽象化、パラダイム乖離）
      • 腐敗防止層（次回）
    • 設計の質が悪くなくスタイルにも互換性がある場合
      • 順応者
• 方法
• 上流チームに隷属する
  • ユビキタス言語も上流から一部共有する
• 制限
  • 上流モデルの能力に依存する
• 共有カーネルとの相違点
  • 2つのチームの責任関係

 ASP.NETなどのアプリケーションFWを利用する場合は順応者であることが良い場合が多い?

残りは次回の人へ・・・・