以前（http://yuutookun.hatenablog.com/entry/2015/04/04/190539）、ドメイン駆動に関して調べてみてから、ちょこちょこ勉強しつつ、ちょうど自分の新規プロジェクトが動き始めたので、反映させてみた感想をまとめてみました。
概要
・採用したDDD手法
・言語
・パッケージ構成
・どうやって作っていったか
・良かったところ
・悪かったところ
採用したDDD手法
昔ながらのレイヤードであったり、オニオンだったり、ヘキサゴナルだったりありますが、
今回はクリーンアーキテクチャを採用しました。
言語
Scalaで実装しています
パッケージ構成
以下を参考に作成しました。
https://speakerdeck.com/yoskhdia/ddd-plus-clean-architecture-plus-ucdom-fullban
http://qiita.com/kondei/items/41c28674c1bfd4156186
https://speakerdeck.com/usrnameu1/genbafalsekurinakitekutiya-scala-play-puroziekutoshe-ji-falseohua
|- domain # データモデル
L enum # ドメインに定数
|- usecase # コアロジック（旧Model）, 別パッケージからは呼び出さない
|- util or service # 状態を持たないutil系
L adaptor # 各usecaseとcontrollerと橋渡し (daoとのやり取りなど)
|- repository # DBとのアクセス
|- input # リクエストを受け取る型の定義
|- output # レスポンスを受け取る型の定義
L transformer # repository層とuse case層の型変換
|- controller # リクエスト受け取り部分
|- input # リクエストを受け取る型の定義
|- output # レスポンスを受け取る型の定義
L transformer # controller層とuse case層の型変換
進め方
ドメイン駆動開発（以下DDD）は、ドメインエキスパート（そのビジネス領域に関してのエキスパート）との対話によって、設計を行う手法です。
まずは、何がエンティティで何が値オブジェクトかを確定させます。
エンティティに応じた操作をusecaseで記述します。
DBとのアクセスはrepositoryを通じて行います。
http ⇔ controller ⇔ use case ⇔ repository ⇔ DB
entity
良かった点
DBで使うオブジェクトとフロントで使うオブジェクトがキレイに切り離されるので、影響範囲が特定しやすいです。
Entityをベースに考えるので、アウトプットを変えたいと言う時に、アウトプットのオブジェクトを作って、そこにEntityの情報を突っ込むだけで追加できるというのが変更に強いです。
悪かった点
やはり、モデルの変換が多いため、実装がどうしても多くなってしまいます。
所感
まだそこまで大きな範囲には適用していないのですが、DDDの威力が垣間見れました。
特にScalaは、DDDと相性がいいなーと思った次第です。
