【ミライトデザイン社内勉強会#10】「IDDD本から理解するドメイン駆動設計」輪読会~1章「DDDへの誘い」~

ドメイン駆動設計のメリットと始め方 ～ 1章「DDDへの誘い」 (1/3)：CodeZine（コードジン）

『顧客と開発者が共通言語で会話して、一体感あるチームとして、事業価値の高いソフトウェアを開発する手法』
高品質はバグのないという意味ではなく、ビジネス的にも成功していることを指します。

戦略的設計と戦術的設計がある

• 戦術的設計だけを取り入れているものが軽量DDDと言われたりする
• 戦術的設計は戦略的設計をどう実装するかを考えるためにある

軽量DDDになるのはどんな原因があるの？

• 技術者が技術のことにしか興味がないから起こり得るのかも
  • Entitiyや集約などの実装のやり方にしか注目していないと起こりがち
• 開発者が単独でDDDをすることはできないので、戦術的設計ができない環境もある
  • 顧客（ドメインエキスパート）と一緒に開発することが必要

戦略的設計でドメインエキスパートと話合ったことをそのままプログラムとして実装する

• ここで使われるのが戦術的設計
• 設計したモデルがそのままコードに落としこまれている必要がある
• 開発者と顧客が一緒にビジネスを考えられるようになる
• 戦術的設計は要するに単なるオブジェクト思考
  • 業務をオブジェクト化して手続き型じゃなくてオブジェクト指向で書こうって話

ユビキタス言語

• DSLの一種
  • DSL（ドメイン固有言語）
    • ある領域だけで通用する言語
• 顧客と技術者で同じ呼び方で統一する
  • 例えば、同じ状態のユーザーのことを顧客側では一般会員、技術者側では無料会員と呼んでいるなど同じ対象に対して呼び方が違うと会話に齟齬が生じることにもなる
    • 顧客側でも呼び方がまちまちだったりするので、チーム内で統一する必要がある
• ユビキタス言語をそのままモデルに落としこむ
• さらにモデルをそのままコードにも落としこむ
  • ユーザーが氏名を変えるならそれはユーザーモデルに氏名を変更するメソッドがあるべき
    • コントローラーとかにユーザーの氏名をDBから直接変更するようなメソッドが存在してはいけない
• ユビキタス言語がないとシステムのことを顧客に説明するときに苦労する
  • ユビキタス言語がモデルに落とし込まれていると、プログラミングの知識がない人にもモデル図などを見せながらシステムのことを説明することができる。

ユビキタス言語ってどうまとめるのがいの？

• 概念モデル図を作ってそれをユビキタス言語集みたいにしている
  • 概念モデルのサンプル - Ken's Blog
  • 図だと関連まで表せるので顧客にも説明しやすい
• ユビキタス言語の辞書を作ってるところもある
• テキストドキュメントだと、すでに追加されているかどうかがわからなくなったりすることもある

途中でコンテキストを分けることはあるのか？

• 1つだっかものが別れるとかは普通にありそう
• 複数のものが1つになることはありえなくはないけど、基本なさそう
• コンテキストが別れる = 別コンテキストのことは全くわからないということ
  • Published Languag（apiから返ってくるjsonとか）でのみでしかやりとりはできない

コアドメインに集中することって具体的にはどういう意味？

• 技術的な問題（SQLとか）とビジネスロジックを分けてドメインに集中するってこと
• ソースコード上ではコアドメインとサブドメインに違いは特にない
• hiroコアドメイン参考
• ビジネスがプログラムを作成した後に変化しないことはほぼありえないので、ビジネスが変化するとモデルが変化する、モデルの変化にプログラムが追従できることがDDDのメリット
• ドメイン駆動設計はモデル駆動設計の中の一部
  • LPのような単発ものにはコストがかかりすぎるのでDDDである必要はない

エヴァンスは日本語翻訳版の序文にて「DDDの原則」は次の3つと述べています。

コアドメインに集中すること
ドメインの実践者とソフトウェアの実践者による創造的な共同作業を通じて、モデルを探究すること
明示的な境界づけられたコンテキストの内部で、ユビキタス言語を語ること

開発が進むにつれてDDDの技術的な側面に集中しまうことがあるかもしれませんが、DDDの本質を見失わないようこれらの原則を意識しておくことは重要です。

アジャイルを前提としたDDD

なお、DDDはアジャイル開発を前提としています。そのため、アジャイル開発の経験があるメンバーのほうがDDD導入がスムーズになる可能性があります。

　また、DDDでは設計段階から、アジャイルの概念における「テストファースト」でモデルを検討することが可能です。例えば、新しいモデルの概念がドメインに出てきた場合、以下の流れで開発を行います。

1   ドメインで必要とされるモデルについて、チーム全体で検討する
2   どのように使用するかについて、チーム全体で考える
3   開発者は、テストコードを書く
4   開発者は、ドメインモデルのコーディングを行う
5   開発者は、リファクタリングを行す
6   ドメインエキスパートは、テストコードを見て、ユビキタス言語の認識が正しいかを確認する

次回

【ミライトデザイン社内勉強会#11】「IDDD本から理解するドメイン駆動設計」輪読会~第2章「ドメイン」「サブドメイン」「境界づけられたコンテキスト」を読み解く~ - Qiita