DDD とは

ソフトウェア開発手法のこと

ソフトウェアとは
- ソフトウェアを適用する対象の何らかの問題を解決する
ドメイン
- ソフトウェアで問題解決しようとする対象のこと
モデル
- 問題解決のために、物事の特定の側面を抽象化したもの
ドメインモデル
- ドメインの問題を解決するためのモデル
データモデル
- データベースに何かを永続化するためのモデル
良いモデルとは
- 問題解決ができるモデル
良くないモデルとは
- 問題解決ができないモデル
  - 現実に即していないモデル
良いモデルを作るにはどうすれば良いか
- ドメインに詳しい人から知識を得る
- 運用した知見をモデルにフィードバックして改善する
- モデルは最初から完成しない、改善していくもの
コードとモデルが乖離した場合は
- モデルの更新をコードに正しく反映できない
  - バグが発生しやすくなる
    - モデルをそのまま表現したコードとなるのが望ましい
      - オブジェクトでモデルを表現する
- モデルからコードを理解しにくくなる
  - ドメインに対する理解もできない
  - モデルは改善されない
  - ソフトウェアの価値を高めにくくなる
    - コードにも継続的に反映しないといけない
    - 頻繁な変更に耐えうるには、拡張性の高い設計が必要
    - これはソフトウェアとしては非常に高い要求
    - EntityやRepositoryなどのデザインパターンが生まれた
軽量DDD
- DDD の実装パターンだけ取り入れること
どうやってモデリングするのか
- 体系的なものは色々
- ユースケース図
  - ユーザーとアプリケーションの相互作用を定義する
  - ユースケースの具体化・言語化
    - 具体化しないと、どのようなモデルを作ればいいかわからない
    - 「タスク」はいち作業者としての視点と管理者としての視点でドメインモデルが変わってくる
- ドメインモデル図
  - クラス図の簡易版
  - 業務の「ルール・制約」（＝ドメイン知識）を吹き出しで記述する
  - 集約の範囲を明記する
集約
- 必ず守りたい強い整合性を持ったオブジェクトのまとまり
- 必ずまとめて取得して、まとめて更新する単位
アーキテクチャーのお話
- What ?
  - アプリケーション層（＝UseCase層）
- How ?
  - ドメイン層

QA

2020.3.8 ドメイン駆動設計モデリング/実装入門勉強会 | sli.do

質疑メモ：
既存のシステムにDDDを適用していく場合どこから手を付ければいいでしょうか
→オブジェクト指向っぽいコードに落としてみる。モデリングしてモデルオブジェクト,Entityつくる
特定の重要機能からレイヤーを意識してアーキテクチャ見直す
#ddd_guide
— paichi (@paichi81) March 8, 2020

質疑メモ：バリデーションは、どのレイヤーで行うのがよいのでしょうか。
→例外の内容・種類による。特定のどこかでなく、層に応じて行う
#ddd_guide
— paichi (@paichi81) March 8, 2020

質疑メモ：吹き出しに書かれたビジネスルールをコードに落とし込んだ後、仕様として何らかの形で管理・維持されるのですか？
→PlantUMLでかいてgitで管理。モデル図をマスタにする
#ddd_guide
— paichi (@paichi81) March 8, 2020

質疑メモ：マスタ管理系の画面でもDDDで実践すべきか？
→ポリシによるがアーキテクチャを画面によって変えるよりは、システムによって揃える。適用しない場面は理由をそえて区切る
#ddd_guide
— paichi (@paichi81) March 8, 2020

質疑メモ：Repositoryの例で殆どがEntityを返す例しかないのですが、Entityのフィールドすべてを返す必要のない場合、DTOを作成してRepositoryから返すのは良いですか？
→8章参照。CQRS、更新と参照のモデルを分離
#ddd_guide
— paichi (@paichi81) March 8, 2020

質問：DDDをどうやって布教してますか？
回答：自身の発言力を高める・仲間を増やす・こっそりやって実績を積むなど、政治的な手法が有効。
#ddd_guide
— ゆうのかんや@セキュリティエンジニア(よわよわ) (@yunokanya) March 8, 2020

質問「モデリングのコツを知りたいです」
回答「モデリングとコーディングを短いサイクルで回す。小さい規模で開発・失敗を繰り返して経験を積む。」
#ddd_guide
— ゆうのかんや@セキュリティエンジニア(よわよわ) (@yunokanya) March 8, 2020

質疑メモ：ドメイン定義があやふやで変化が速い。DDDは適用できるか
→"6.8.1 ドメイン層にロジックを寄せる"参照。
最も重要なドメイン層を、独立させて修正しやすくする。
むしろ適用していくべき
#ddd_guide
— paichi (@paichi81) March 8, 2020

# 心に残るツイート

#ddd_guide
質問中によく出てきた松岡さんお勧めのPlantUMLはこちら！https://t.co/1qSpOGaB8x
— へー/heisy (@heisy) March 8, 2020

「フロントエンドでDDD」がややこしく思えるの、サーバーと全く同じ視点・関心・手法でやろうとするからであって、まさしく「フロントが果たすべき責務」をドメインと捉え、そのために必要な道具立ては何かを考えれば良い、と考えてます。#ddd_guide https://t.co/GrsMhUwKtI
— philomagi@技術書典応援祭「Vue3解体新書」5章寄稿 (@Philomagi) March 8, 2020

ORマッパーはリポジトリに閉じ込める。確かに。
昔の自分のコードを、DDDっぽくリファクタリングすると実感できる。
#ddd_guide
— hideki@鉄分多め (@yossy52) March 8, 2020

ドメインモデルとデータモデルの混同というか、「Entityとテーブルは1対1でなくてはならない」という認識が、質問の後ろにありそうな#ddd_guide https://t.co/cfSbFdPSzl
— philomagi@技術書典応援祭「Vue3解体新書」5章寄稿 (@Philomagi) March 8, 2020

下手なコードを書くと、マサカリが怖くて萎縮することもあるが、成長するためにはとにかく書いて経験を積むしか無い。
#ddd_guide pic.twitter.com/BPYJFqkKiy
— ゆうのかんや@セキュリティエンジニア(よわよわ) (@yunokanya) March 8, 2020

#ddd_guide ドメイン駆動設計 モデリング/実装入門勉強会(オンライン) に参加した

DDD とは

QA

#ddd_guide ドメイン駆動設計モデリング/実装入門勉強会(オンライン) に参加した