6月 072019
 
Pocket

とりあえず最も重要な哲学的な部分だけメモ。
これ以外に本に書かれている内容は具体的なモデリング技法のパターン。

読んだ本

ドメイン駆動設計の哲学

  • DDD(Domain Driven Design) と略される
  • ソフトウェアは複雑になりがちなものである
  • 複雑さの核心とは、問題のドメイン(解決しようとしている業務領域)自体が本質的に複雑であるという点に着目
  • ドメインの複雑さに対処するためには、優れたドメインモデルが必要となる
  • そのドメインモデリングを主軸にソフトウェアを設計していく手法が DDD
    • 設計手法であり開発プロセスではない
    • 最後の D は Design であって Development ではない!

ドメインとは?

  • 業務や事業そのもの(すなわち領域)を指す
    • 領域=Domain
    • 例: 企業活動のうち会計業務のことを会計ドメインとして捉える
    • 例: 企業活動全体を1つのドメインとして捉えた場合、会計ドメインはその企業の業務ドメインのサブドメインとなる

モデルとは?

  • 現実世界の物事(概念)は複雑すぎる
  • 特定の問題について考える際、注目すべき要素のみ抽出して考える必要が出てくる
    • 例: トイレの設計では、性別は重要であるが名前は重要ではない
    • 例: 荷物の配送では、宛先は重要ではあるが性別は重要ではない(相手が人間でない場合すらある)
    • 例: 電車賃の計算では、経路、大人/子供、特急などは重要だが、車両、人の識別、支払い方法などは重要ではない
  • これらのようにコンテキストを定め、必要な概念を発見して捉える作業を、抽象化=モデル化という
  • 抽象化された概念をモデルという
    • モデルを図式化したもの(モデル図)はモデルそのものではない
    • 図は「伝える」「整理する」等の目的があるので、その分情報が削られる
    • DDD ではモデルの詳細はコードで表現し、保守する
    • 図やドキュメントはコミュニケーションのために補足的に用いる

ドメインモデルとは?

  • ドメインをソフトウェア化するというコンテキストでモデル化したもの
    • ドメインを抽象化し、ドメインモデルという概念を発見する
    • ドメインモデルを表現するのに、オブジェクト指向言語によるオブジェクトモデルなどを用いる

どのようにドメインモデリングするか?

  • ドメインの中から最も投資価値の高い部分(コアドメイン)を発見し、そこに集中する
  • 開発者だけではなく、業務をよく知る人(ドメインエキスパート)も協力して作業する
  • モデリングのコンテキストを明示し、他と境界づける(境界づけられたコンテキスト)
  • それぞれの境界づけられたコンテキストの中で、コミュニケーションの為の共通の言語を作り上げる(ユビキタス言語)

原著の構成

エリック・エヴァンスのドメイン駆動設計

  • DDD の哲学とその目標についての内容はほぼ冒頭の第1部のみ
  • 残りはドメインモデリングのフレームワーク(技法)と語彙(用語)について(パターン)

  • 第1部 ドメインモデルを機能させる
    • → DDD の思想・哲学
    • 第1章 知識をかみ砕く
    • 第2章 コミュニケーションと言語の使い方
    • 第3章 モデルと実装を結びつける

  • 第2部 モデル駆動設計の構成要素
    • → ドメインモデルを表現するパターン / 戦術的設計
    • 第4章 ドメインを隔離する
    • 第5章 ソフトウェアで表現されたモデル
    • 第6章 ドメインオブジェクトのライフサイクル
    • 第7章 言語を使用する:応用例

  • 第3部 より深い洞察へ向かうリファクタリング
    • → ドメインモデルを洗練させるパターン / ドメインモデルのリファクタリング
    • 第8章 ブレイクスルー
    • 第9章 暗黙的な概念を明示的にする
    • 第10章 しなやかな設計
    • 第11章 アナリシスパターンを適用する
    • 第12章 デザインパターンをモデルに関係づける
    • 第13章 より深い洞察へ向かうリファクタリング

  • 第4部 戦略的設計
    • → ドメインモデル全体を管理するパターン/ 戦略的設計
    • 第14章 モデルの整合性を維持する
    • 第15章 蒸留
    • 第16章 大規模な構造
    • 第17章 戦略をまとめ上げる

 Leave a Reply