面白駆動人生

やっほー

【読書メモ】実践ドメイン駆動設計 ~第1章~「DDDへの誘い」

1. Why DDD?

  • ドメインエキスパートと開発者を一つのまとまったチームにする。
  • チーム全体が理解できる共通言語に基づいて開発を進められる。
  • 設計がコードであり、コードが設計でもある。
  • 戦略設計と戦術的設計の両面で、健全なソフトウェア開発を支える。

目指すは、事業価値をもたらすソフトウェア開発

事業価値をもたらさない、ソフトウェア開発とは?

  • ドメインエキスパートと開発者との断絶
  • ドメインエキスパート同士の意見の相違と、矛盾したソフトウェアモデル
  • 技術解をベースに進め、事業・業務が間違った方向に向かう

2. どんな時にDDDを使うのか?

  • 事業における、もっとも重要な領域。
  • 置き換えが簡単な領域ではなく、複雑で投資の見返りが一番大きな部分。 ・・・コアドメイン
  • 重要な支援的な領域  ・・・サブドメイン

3. どのようにDDDを使うのか?

ユビキタス言語を作ることが第一歩。

ユビキタス言語 == ドメインエキスパート・ソフトウェア開発者を含めたチームで作り上げる共通言語

どのようにユビキタス言語を作っていくか。

  1. ドメインについて図示し、名前とアクションをつける。
  2. 定義をまとめた用語集、もしくは概念に関するスケッチなどのドキュメントを作る。
  3. 作成した用語・フレーズをレビューしてもらう。

point1. ユビキタス言語・コードは変化するもの。

  • ドキュメントをつくって終わりではない。
  • コード内のモデル・チーム内での会話が、最もユビキタス言語の現状を表す。

最初に作ったドキュメントを常に最新の状態に更新するのは非現実的。 いつでも捨てられるようにと考える。    

point2. ユビキタス != ユニバーサル

ユビキタスは、業界全体・世界中で、という意味ではない。 境界づけられたコンテキストごとに、ユビキタス言語が存在する。

4. 導入する際の課題は?

5. アジャイルとDDD

DDDはアジャイルを想定している。 テストファーストでモデルの検討をする。

  • チームでモデルを検討
  • モデルに対するテストコードを実装
  • ドメインモデルを実装
  • リファクタ
  • ユビキタス言語の認識が正しいか確認する。