LoginSignup
1
0

More than 3 years have passed since last update.

読書メモ:実践ドメイン駆動設計(IDDD)3章

Posted at

はじめに

  • 実践ドメイン駆動の読書メモです。簡単なまとめと、自身のコメントをまとめています。//から始まる行が私のコメントや考察。
  • https://www.amazon.co.jp/dp/479813161X
  • 狙い:本書を読んだものの、頭に入ったようでまったく記憶に残らなかったため、あとで自分の記憶を掘り起こすツールとして。

第3章 コンテキストマップ

  • 2章の内容が「解決空間の評価」にあたるのに対し、本章が「問題空間の評価」にあたる

3.1 なぜそんなにもコンテキストマップは重要なのか

  • DDDにとりかかる最、まずプロジェクトの現状をコンテキストマップに表す
  • 解決空間の全貌を俯瞰できるようにするために行う
  • 巨大な泥団子との統合が求められる時でも、関連をきちんとマップに反映させておくとよい

    • 可視化することで得られる知見
    • どこでチーム間コミュニケーションが必要になるかを判断できる
    • // 巨大な泥団子というのは、理解が難しく、レガシーで、巨大なサービスをイメージすると良さそう
  • コンテキストマップを描く

    • コンテキストマップは現状を書くもので、将来像を描くものではない
    • 凝った作りにする必要はなく、ホワイトボードなどのマーカーで手書きするなどでよい
    • あまり細かく儀式的な作業をしても、チームの助けにはならない
    • コンテキストマップをオープンにして、議論の中から知見を見つけるためのツールとして使う
  • プロジェクトと組織的な関係

    • 境界づけられたコンテキスト同士の関係にはパターンがある(説明は個人的に気になったポイントのみ)
      • パートナーシップ
        • 成功/失敗の運命を共にする。相互が密接に関わっている。
      • 共有カーネル
      • 顧客/共有者の開発
        • 上流/下流の関係で、下流の結果に上流の成否が左右される。
      • 順応者
        • 上流/下流の関係だが、上流側が下流の要求に応える動機がなく、下流が上流に合わせる形。
      • 腐敗防止層
        • 上流の機能を下流のドメインモデルの用語で表現する、情報の変換インタフェースの層。上流の変更に対する防御層。
      • 公開ホストサービス
        • サブシステムにアクセスできるプロトコルを公開し、別のサブシステムから使えるようにするもの
        • RESTベースのリソースとして実現できる。RPC、メッセージング。
      • 公表された言語(Published Language)
        • コンテキスト間での共通の言語。コンテキスト間のれん系はPLを介して行われ、それぞれのコンテキストのモデルの言語へと変換して使用する。
        • XML、JSONなど
      • 別々の道
        • お互いにとって不可欠ではないなら、切り離す。
      • 巨大な泥団子
        • あるシステムの各部分がどれも大規模でモデルが混在しており、境界も辻褄が合わない。キレイにするのは諦めて、巨大な泥団子として扱い、その悪影響が他のコンテキストに及ばないようにする。
      • // コンテキスト間は「公開ホストサービス上」に流れる「公表された言語」でやり取りし、それぞれの受け口が「腐敗防止層」として働く、というイメージかなと思います。これによって、相対するサービスが巨大な泥団子のであったとしても、そのイケてない設計の影響を受けなくできる、ということかと。自分たちのサービスや主管組織、連携するサービス・企業などを上記の用語で整理することで、見えてくるものがありそう。この可視化による発見の創出こそが、コンテキストマップの役割なんでしょうね。
    • コンテキストマップにおける、上流・下流の意識は重要
  • コラボレーションコンテキスト/アジャイルプロジェクト管理コンテキスト/認証・アクセスコンテキストとの統合

    • 自立性を確保するために、依存する別システムのオブジェクトの状態をキャッシュする。ただし、この時、まるごとキャッシュするのではなく、ローカルにドメインイブジェクトを作り、ローカルのモデルには必要最小限の状態だけを保持するようにして、別システムのオブジェクトを変換するようにするほうがよい。
    • コンテキスト間の連携の事例(バウンダリーオブジェクトや腐敗防止層についての例。各論なので記載しない)
    • RESTベースのリソースをローカルのドメインモデルのオブジェクトに変換するためのマップの作り方の例

3.2 まとめ

  • 以下、本章を読んだ個人的見解のまとめです。
    • // 設計・実装状は、RESTであるとか、変換オブジェクトであるとか、色々あるが、「腐敗防止層」であるとか「公表された言語」であるとかの定義がなされた上で考えてみるのは面白いと思いました。
    • // コンテキストの関係を上流・下流を意識するのも良いですね。
    • // なお、割と具体的で各論的な内容が多かったので読書メモに書く内容が少なかった…。後で見返そう。
1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0