ドメイン駆動開発勉強会 ①

ドメイン駆動開発
勉強会 ①
ドメイン駆動開発とはなんぞや…？

目次
ドメイン駆動開発とは
ドメイン駆動開発の目的
ドメインレイヤーの考え方
case study: boundary Upload
今日のまとめ

免責事項
あくまでも菊池の過去経験・学習濃度による解釈が混じっ
ているのでエリック・エヴァンスの意図と違う解釈が入っ
ているかも知れません
※ それに気付いたら免許皆伝
DDDをかじったことのあるひとからすると物足りない内容
になっています

ドメイン駆動開発とは
世の中で話題のドメイン駆動開発（以下、DDD）
そもそも「駆動開発」ってなんやねん？
DDDが意味するところはなんなのか？
DDDの文脈で語るときに意識したい
いくつかのことを
紐解いていきます

駆動開発って？
世の中に溢れる様々な駆動開発
BDD
TDD
MDD
YDD
DDD
（ドメイン駆動開発）

世の中に溢れる様々な駆動開発
BDD
（振る舞い駆動開発）
TDD
（テスト駆動開発）
MDD
（モデル駆動開発）
YDD
（嫁駆動開発）
DDD
（ドメイン駆動開発）

動力源・力の加えるポイント・起点を明示した開発手法
ex: 「スキーマファースト ≒ スキーマ駆動開発」
● TDD: テストを起点に開発をする
● YDD: 嫁の要望を動力源に開発をする
● MDD: しっかりDSLで設計してから開発をする
● DDD: ソフトウェア化する対象を抽出して開発する

DDDが意味するところは
なんなのか？

ドメイン = [ソフトウェアにする対象] を起点にした開発手法
ライクルの「ソフトウェアにする対象」ってなんだろう
か？

[ソフトウェアにする対象]
例: 配送システム
「人がものを運ぶ」その過程をソフトウェアにしたい

→ DDDの出発地点

「配達員が貨物を倉庫からお客様へ運ぶ」管理のソフトウェア
→ ユビキタス言語・コンテキストの整理

「配達員は配送車で移動をして複数の貨物を運搬する」
「貨物は配送IDがふられて重量が配達価格になる」
「倉庫は多くの貨物が格納されており配達員が常駐している」
→ ドメインモデリング

「配達員は配送車で移動をして複数の貨物を運搬する」
「貨物は配送IDがふられて重量が配達価格になる」
「倉庫は多くの貨物が格納されており配達員が常駐している」
この過程を起点して改善するのがDDDであるべき形

DDDの文脈で語るときに
意識したいこと

DDDの文脈で語るときに意識したいこと
Entity
ValuObject
domain / model
「あれ？僕の知っているDDDってこんな感じだった気がする…」
って人いないですか？
リポジトリ
集約
ファクトリー
クリーンアーキテクチャ
レイヤードアーキテクチャ

Entity
ValuObject
domain / model
すべて間違ってないけど本質ではない
リポジトリ
集約
ファクトリー
クリーンアーキテクチャ
レイヤードアーキテクチャ

すべて間違ってないけど本質ではない
エリック・エヴァンス本でも語られている
コードの書き方・設計手法は「戦術的DDD(軽量DDD)」
と言ってドメインモデリング(設計)後のコードをどうやって
現実の形に近づけるのか？に対する一つの回答
コードはキレイになるがDDDの真骨頂ではない

ドメイン駆動開発の目的
DDDの真の目的とはなんでしょう？
最終的にきれいなコードを生み出すことなのか
開発コストを下げる取り組み設置なのか
技術負債に向き合うための仕組みづくりか

DDDの真の目的とは
「戦術的な側面も明文化されているから最終的
にきれいなコードを生み出すことなので
は？」
「テスタブルになりそうで設計良くするから開
発コストを下げる取り組みがしたいので
は？」
「そもそも事業に近いドメインを整理して技術
負債に向き合うための仕組みづくりかもね」

ソフトウェア化する対象の
問題を解決すること！！

脳裏に焼き付けてください

ソフトウェアにしたい対象を定めて
ユビキタス言語・コンテキストを整理して
丁寧にドメインモデリングを行ったのも
ソフトウェア化する対象の問題を解決することが本丸
ドメインモデリングもそれに即して以下の定義がある
「問題解決のために、物事の特定の側面を抽象化したもの」

ソフトウェアにしたい対象を定めて
ユビキタス言語・コンテキストを整理して
丁寧にドメインモデリングを行ったのも
ソフトウェア化する対象の問題を解決することが本丸
ドメインモデリングもそれに即して以下の定義がある
「問題解決のために、物事の特定の側面を抽象化したもの」
つまり、対象の問題に関係ない情報は全て無駄

配達員は以下の就業規定・福利厚生があるとして
● 走行距離に応じて休養を取る必要がある
● 配達数に応じてインセンティブ報酬でボーナスが与えられる
● 子どもがいるなら誕生日休暇が付与される
○ 休んだら5000円の特別報酬がもらえる
「配達員が貨物を倉庫からお客様へ運ぶ」管理の
ソフトウェアというコンテキストでは全て無駄

ドメインレイヤーの考え方
DDDという抽象度の高い手法
ビジネスロジックを守る取り組みのイメージ
その戦術というところを垣間見る

問題解決を行うための心がけ

ソフトウェア化する対象 = ドメインの問題解決を行う
それを阻害する一番の要因はなんだろうか
[問題解決の一番の障害]

● ドメインモデルが正しく表現されない
○ ユビキタス言語・コンテキストの不一致
○ 技術的な関心事がドメインモデルに混ざる

● ドメインモデルが正しく表現されない
○ ユビキタス言語・コンテキストの不一致
○ 技術的な関心事がドメインモデルに混ざる
一番厄介で見落としやすい観点

そもそもソフトウェアエンジニアは「技術を用いて問題解決をする」
どうしても方法論として技術のコンテキストが入り込みやすい
● 認証認可
● 暗号化・秘匿化
● 遅延実行
上記の考え方が入り込むのは問題ないが特定技術に寄った考え方を
ドメインモデルにもたせてはいけない

大事なことは
「ビジネスの関心」と「技術の関心」をうまく分離して
「ビジネスの関心」をドメインモデルに閉じ込めること
● ドメイン層はstruct / classの置き場所ではない
● ドメイン層は「ビジネスの関心」を表現する場所である
表現力を上げるための戦術的DDD
- Entity / ValueObject / Aggregate / Service

今日のまとめ
今日の内容をおさらいして
DDDのファーストステップを踏み出そう

ドメイン = [ソフトウェアにする対象] を起点にした開発手法
● ソフトウェアにする対象を定める
● ユビキタス言語・コンテキストを整理する
● ドメインモデリングを行う

コードの書き方・設計手法は「戦術的DDD(軽量DDD)」
で技術的関心としてフォーカスされがちだけど
DDDの本質・真骨頂ではない

ドメイン駆動開発勉強会 ①

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à ドメイン駆動開発勉強会 ①

Similaire à ドメイン駆動開発勉強会 ① (20)