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

[im-higashi]

モデル

• 膨大なドメインの知識を要約したシンプルでわかりやすい説明
• モデリングスキル=要約力
  • 重要な要素を発見する力
  • 本質でないものを削る力
  • 厳密に組み立てる力

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

• 1つのモデルとして独立してそうな範囲
  • 開発チーム
  • 運用チーム
  • コードベース
  • データベーススキーマ
• 一つのモデルが適用できる範囲の制限
• モデルの一貫性を保つ努力ができる範囲
• チームの言葉であるユビキタス言語が通用する範囲
  

• DDDとコンウェイの法則

システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう

• 1チーム1サービス
  • コンテキストをモデル・ユビキタス言語の適用範囲とすると効率性などで1チーム1サービスが良いのでは
• https://www.infoq.com/jp/news/2017/02/ddd-perfectionists

腐敗防止層

他のシステムへのメッセージ送信する仕組みではなく
むしろ
モデルやプロトコルの持つ概念オブジェクトやアクションを別のものに変換する仕組み

設計

セマンティクス変換

実装

ファサード:

• クライアントのためにアクセスを簡略化、隠蔽する（詳細にたちいらせない）
• ファサードは基盤となるモデルをへんこうしない

アダプタ:

• 振る舞いを実装してる側が理解してるものとは別のプロトコルを使えるようにするラッパ
• アダプタと変換サービスは分ける

別々の道

• 統合は高くつくがそれによる受益は小さい
  • 多くの本質的でないコストが発生する
  • 自身の洗練されたモデルが影響を受ける
• 別々の道を選択すると閉ざされる選択肢がある
  • 制御は一切不能となる

統合による樹液とコストのトレードオフかな

公開ホストサービス

• 利用場面
• あるアプリケーションが他の多くのアプリケーションから利用されるような場合
• 方法
  • 1つ1つについて変換層を用意するような面倒をせず、プロトコルが公開された共有サービスの形にする
  • サービスの機能を拡張したいときは、プロトコルを拡張

公表された言語

• 利用場面
  • コンテキスト間連携の通信媒体として、共通の情報モデルを定めたい
  • しかし、既存の自家製ドメインモデルでは不適切なことが多い
    • モデルが未成熟だったり、無駄に複雑だったり、あるいは文書化されていなかったりするため
  • きちんと文書化されていて広く周知された共有言語を採用するのが良い
• 例
  • protocol
    • HTTP
  • データ
    • XML
    • JSON
  • シリアライズ言語
    • protcol-buffers
    • Message pack

象のモデルを統一する

モデルコンテキスト戦略を選択する

チームでの意思決定とより上層での意思決定

コンテキストに自ら身を置く

境界を変換する

変更できないものを受け入れる：外部システムの輪郭を描く

外部システムとの関係

• 統合が必要かで以下を検討
  • 順応者
    • 順応者は拡張のみに専念して既存モデルの修正はNG
  • 腐敗防止層

設計中のシステム

• 境界づけられたコンテキストをチーム間で維持するのはNG
  • 継続的な統合など考えると困難
  • 共有カーネルや依存関係があるなら顧客／供給者の開発を検討

別のモデルで特殊な要求を満たす

デプロイ

• どの戦略をとってもデプロイには影響がある
  • 顧客／供給者の開発
    • お互いのバージョンリリースの調整必須
    • コードとデータの移行も一緒に実施必要
  • 共有カーネル
    • より困難

トレードオフ

すでにプロジェクト進行中の場合

• 現状に従って境界づけられたコンテキストを定義する

変換

コンテキストのマージ

• 別々の道⇒共有カーネル
  • 単一コンテキストへ行くまでに共有カーネルを一旦経由すべき

• 共有カーネル⇒継続的統合

レガシーシステムを段階的に廃止する

公開ホストサービス⇒公表された言語