tokenの日記： DDDが把握できない

エリック・エヴァンス本を読んでるんだけれど、どうにも翻訳が不十分なのか原文がそうなのか分からないけれど、説明文の途中で視点があっちこっちに飛び回るのでなかなか頭に入ってこない。印象は英文を機械翻訳した日本語を読んでいるような文章の違和感。

ざっと理解したことは、（１）ドメインモデルをまず作らなければならない（２−１）ValueObjectでスコープを狭める（２−２）レイヤーを分けて依存性をコントロールする（２−３）EntityにIDを付与し集約で末端まで復元する？

という感じで、概念に関してはドメインモデリングとヘキサゴナルアーキテクチャ。実装に関してはDomain / ValueObject / Entity / Factory / Storage / Interface など。巷に転がってるDDDのまとめ的なページは、大概が実装に関して説明してる。キーワードが明確だから分かりやすいっちゃ分かりやすいんだけれど、飽くまで実装の話なのであんまり分析という観点では役に立たない。実装方法が分かったところで、分析がままならないのでは、氷の入ってないかき氷機を回すが如く。

DDDでの分析によって、オブジェクト指向のなんたるかが掴めるかと思ってたんだけれど、DDD砂漠にハマったまま出てこれない感じ。

DDD解説でよくある系例題が銀行の出納処理。全くもって普段とは関係ない業務内容の事例でイマイチな感がある。エヴァンス本の荷物搬送サービスにしても、なんだかなぁと。もっとも、業務＝エキスパートの観点からToDoリストみたいな例題は馴染まないんだけれど、なんかもっと身近な業務システムってないもんかなぁ？と思わないでもない。

ただまあ、極初期という事を考えて業務でなくとも良いと割り切ってToDoリストみたいな例題だったり、もう存在意義が不明なカウンタやBBSのようなシンプル構造のウェブアプリをDDDで噛み砕いてみるとか、やってもらいたいなあ。

https://creators-note.chatwork.com/entry/2017/12/10/160210

かとじゅんさんのICONIXの例を読むと、ロバストネス図かシーケンス図でEntityに対してControllerが振る舞いをする＝Entityの振る舞いに入力を与えるのがControllerとなるので、Entityがドメインモデルで、ロバストネス図のControllerの具体的な処理がドメインモデルが持つ振る舞いと把握した。ちょっと進展した気がする。エヴァンス本では分からなかったかもしれない。とりあえず、漏れがあるかもなのでエヴァンス本も読むわけだが。