【読書感想文】DDD(ドメイン駆動開発)について①

はじめに

最近.NETエンタープライズアプリケーションアーキテクチャ第二版を分からん分からん言いながら読んでるので、 メモついでにブログ記事にしました。

.NETのエンタープライズアプリケーションアーキテクチャ第2版　.NETを例にしたアプリケーション設計原則

DDD(ドメイン駆動開発)

「抽象的な設計原則を現実のソフトウェアに適用する」 というのが開発者のエリック・エヴァンスさんが提唱したDDDの概要です

はい、サッパリですね

今回は、DDDで扱われいる用語を自分なりにまとめて行きます

DDDによる分析

DDDによる分析の要素はユビキタス言語と境界付けられたコンテキストの2つ。 この2つは互いに関連しあっている。

• ユビキタス言語

  • ユビキタス(いつでもどこでも誰でも)という意味が指すとおり、プロジェクトの関係者全員が使用する言語
  • ビジネス側と開発側の概念を統一し、拡張したもの
  • プロジェクト内のあらゆる場面でのコミュニケーションにおいて使用される事が理想
  • アーキテクト(設計者)はドメイン対する知識を深めながら、名詞と動詞を語彙に追加していくことになる
    • 1つのビジネスドメインにユビキタス言語を追加していく中で、名詞・動詞の重複を見つけ、それを複数のサブドメインに分割していく可能性を見つける
  • ユビキタス言語は、聞き取り調査や話し合いの中から生まれる
  • ドメインモデルで利用される命名規則とコーディング規則にはユビキタス言語の命名規則が反映されているべきである
    • ユビキタス言語が更新された場合、命名とコーディング規則も合わせて更新を行う

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

  • ドメインの領域の内、独自のユビキタス言語を持つため別個に扱ったほうが良い領域のこと
  • 境界付けられたコンテキストごとに、適切なアーキテクチャを決定する必要がある。
  • アーキテクトの主な役割は、ドメインから、ドメインごとのコンテキストを洗い出しサブドメインことにある
    • この洗い出しをコンテキストマッピングという
  • ユビキタス言語を変化させるのであれば、新しい境界付けられたコンテキストが発生したということ
    • 1つのビジネスドメインの中で同じ用語が別の意味で扱われていたり、異なる用語が同じ意味で使われていた場合に、そのビジネスドメインは複数のサブドメイン分ける必要があると言える
  • コンテキストの数と境界付けられたコンテキスト同士の関係が、企業の物理的な組織を反映していることもよく有り、部署ごとにコンテキストが定義されるのが一般的
    • 大抵は境界付けられたコンテキスト毎に開発チームが割り当てられる
  • コンテキスト間で重複した言語を共有カーネルとして共有事も可能だが、コンテキストAで行われた変更でコンテキストBのコードが動かなくなるなど、弊害は多い

コンテキストマッピング

• コンテキストの種類

  • 上流コンテキスト
    • 下流に影響を与えるコンテキスト
    • 下流を一方的に変更することがある
  • 下流コンテキスト
    • 受動的であり、上流コンテキストによって変更される

• コンテキストマッピングの関係パターン

  • ACL(腐敗防止層)
    • 最も安全な関係パターン
    • 一方の上流コンテキストが変更された際にコンテキストを同期させるために必要な変更が全てACLに分離される
    • 外部サービス、レガシーコードをカプセル化していル場合に有効
  • Conformist (順応者)
    • 下流コンテキストは上流コンテキストに受動的に従う
    • 下流コンテキストは上流コンテキストの必要のないデータまで受け取る
  • Customer / Supplier (顧客/受給者)
    • Conformistに近いが、不要なデータが送信されないようにチーム間で協力が発生する点が異なる
  • Paetnership
    • 二つのコンテキストは別々に開発されコードの共有は行われないが、相互依存しておりリリースや変更の際には双方を無視できない
  • 共有カーネル
    • 二つのコンテキストがモデルの一部を共有する
    • 共有カーネルを変更するにはチーム間の同期が必須

コンテキスト毎にアーキテクチャを定義する

• 階層化アーキテクチャ
  • DDD分析から見つかるアーキテクチャの内で最も一般的
  • 元は、プレゼンテーション層/ビジネス層/データ層の三層構造であった
    • 最近(2014年頃)では、プレゼンテーション層/アプリケーション層/ドメイン層/インフラストラクチャ層で構成される
  • プレゼンテーション層
    • UIを提供する画面の集まり
    • 各画面には、データが読み込まれその画面のアクションは明確に定義されたデータを転送する
      • アプリケーション層から、プレゼンテーション層に追加されるデータをビューモデルと呼ぶ
        • 逆に、プレゼンテーション層からアプリケーション層に渡されるデータを入力モデルと呼ぶ
  • アプリケーション層
    • プレゼンテーションの指示に従い、アクションを手配する層
      • つまりは、ユースケースの実装を取りまとめる層でもある
  • ドメイン層
    • ドメインモデルとサービスで構成される
  • インフラストラクチャ層
    • セキュリティ、ログ、キャッシュなどが分類される

次回は、プレゼンテーション層の具体的な扱いについて書いていきます

リンク

次回を作成次第、追加していきます