ドメイン駆動設計を始めようの（第一部 設計の基本方針） 読書メモ
１章 事業活動を分析する
事業領域（ビジネスドメイン）とは何か？
企業が事業活動を展開する領域のこと
例）クロネコヤマトの宅配サービス、スタバのコーヒーなど
業務領域（サブドメイン）とは何か？
事業活動の領域全体を細分化したもの
ドメイン駆動設計（以下DDDと呼ぶ）では業務領域を以下の３つに分類する
- 中核の業務領域（Core Domain）
競合他社との違いを生み出す事業活動
競合他社との差を生み出す箇所であるため必然的に複雑度は高くなる
（簡単に真似ができないからこそ価値が生まれる） - 一般の業務領域（Generic Subdomain）
一般的な業務い領域では優位性を生み出すわけではないので、どの会社も同じようなやり方で行う - 補完的な業務領域
事業活動を支える事業活動
補完的な業務領域を特徴づけるのはその単純さ
ここでも競争優位性を生み出すわけではないので、単純なロジックになる
| カテゴリー | 競争優位性 | 複雑さ | 変化 | 実装 | 課題の特徴 |
|---|---|---|---|---|---|
| 中核 | 🙆♂️ | 複雑 | 多い | 社内 | 複雑で興味深い |
| 一般 | 🙅♂️ | 複雑 | 少ない | 製品や外部サービス | 既存の解決策がある |
| 補完 | 🙅♂️ | 単純 | 少ない | 社内・委託 | 明確 |
業務領域の特徴を捉え、分類することで設計時の判断材料になる
業務エキスパート (ドメインエキスパート)
ソフトウェア開発の対象になっている領域の事業活動に精通した人たち
→対象領域について信頼できる情報源となる人たち
２章 業務知識を発見する
事業の課題
事業の課題は明確な答えがあるものではない
業務プロセスや作業の効率化など多岐にわたる
知識の発見
役立つソフトウェアを設計しようとすれば
最低限事業活動についての基本レベルの知識を把握することが重要である
この知識を持っているのが業務エキスパートである
業務エキスパートにはなれない
→開発者がやるべきことは業務エキスパートの考え方を理解し、同じ言葉を自分たちも使うことである
ソフトウェア開発は学びのプロセスであり、動くコードは学びの副産物
開発を通して業務理解への理解を深めることで課題解決を行う
同じ言葉とは何か？
お互いの意図を効率的に伝えたいのであれば、同じ言葉を使う
ドメイン駆動設計は、業務知識の変換を繰り返す代わりに
事業活動を表現するための単一の言語を育成する
同じ言葉とは事業活動の表現と業務エキスパートの発想や考え方をそのまま表現できる言葉である
同じ言葉には業務用語を含めるのであって、技術用語を含めてはいけない
同じ言葉の目的は、業務エキスパートの頭の中にある事業活動についての知識や考え方をわかりやすく整理することである
一貫性
同じ言葉は正確で一貫している必要がある
言葉の意味をあれこれ推測せずに業務ロジックが明確に表現できることが必要である
曖昧な表現
同じ言葉は、１つの用語が１つの意味に対応することが必要
同義語
同じ言葉では、２つの用語を同じ意味で使うことはできない
意図が違うのであれば、それぞれの用語を特定の文脈ごとに使い分ける
３章 事業活動の複雑さに立ち向かう
異なるモデルの混在
同じ用語が異なる意味で用いられるケースがある
例えば。。
営業促進部門：「見込み客」とはある人が自社製品に興味を持った通知である。
営業部門：営業プロセスのライフサイクル全体を指す、時間をかけて取り組む対象。
以下の様に文脈の意味を識別する情報を付加する方法はあるが
どちらのモデルをどのケースで使用するか判断するのは認知負荷になる。
販売促進の見込み客：marketing lead
営業の見込み客：sales lead
人間であれば、前後の文脈から意味を判断したりする
→ドメイン駆動設計では区切られた文脈(Bounded Context)で対応する。
事業全体をいくつかのモデルに分割して、それぞれのモデルが通用する範囲を厳密
その範囲こそが区切られた文脈である
Discussion