はじめに

※当記事は答えは書いておらず、疑問を持ったままmoyamoyaしたまま終わってしまうのでご注意ください
※私、俺、僕、小生、朕はこんな風にやってるよ！　という意見ありましたらコメントにて教えてくれると非常に助かります
※書いてある内容は筆者のIQが3程度しかないため、非常に読みづらいです。

筆者紹介

ユーザー企業で営業志望で入社するも、無事社内IT部門にぶち込まれる。
入社後すぐにレガシーシステムのリプレイスの赤紙を渡される。
３０００行×∞のExcel仕様書と１万行×∞のソースコード、Excelスクショペタ貼り×∞のテストに問題なく殺害される
プロジェクトは終わり保守期間に入ったが流石にこのままはしんどいので、ドメイン駆動設計を導入しなんとか保守のしやすいアプリを目指す（現在）

Let's DDD!

さあ、DDDをやってみよう！
ということで、チーム内のDDDを知っているメンバーと一緒にDDDを実践。私もチームメンバーも知っているだけで実務でのDDD経験は無いです。

実践するにあたってユースケース駆動開発実践ガイドをもとにやってみましたが、保守案件の納期の関係でユースケース記述、ドメインモデル図、クラス図の作成のみにスコープを絞りました。

最初のユースケース記述の作成とドメインモデリングに3人日ぐらいかけ、その後に実装を行いました。あまり頻繁にモデリング⇔実装のサイクルを回せなかったのが反省点です。

DDDをやってみて

ドメインモデルがコードになっていく時に小さく、安全なオブジェクトになっていくことに感動した（複数の1万行クラス、無限のgetter、setterに頭部を強打され続けているため）
ドメインに対して自動UTテストを行うことで、画面からのE2Eテストと比較するとDBに依存しない安心感がとても高い

疑問

動詞ってドメインにならないの？

ドメインモデリング→コーディングをしていくなかで動詞のドメインモデルがドメイン層に反映されない場面があった。そのドメインはアプリケーション層（ユースケース層）に吸収されたけど、結構記述が多くてドメイン知識っぽい点も多い。
でも確かにエンティティや値オブジェクトとしてモデリングするのは難しい感じはした。動詞には識別子をつけれないのもなんとなくわかる。
例えば「釣銭返却」みたいな言葉があって、釣銭返却で渡すお釣りはお金ドメインと同一だからドメインとしてモデリングせず、アプリケーション層にお釣りを渡す時のルールを書いてしまう。みたいな感じになってしまった。

その他疑問

再構成用にコンストラクタを使うかどうか。現在はアプリケーション層がリポジトリを直接使ってDBに保存されたドメインの再構成をしている
検索系の機能とかでやっぱり詰め替えが多くなってしまう。CQRSを検討したいけれども、検索の時のドメインルールとの切り分けが難しい。

終わりに

ドメイン駆動設計をやってみて、これまで惰性で続けてたシステムの改修に新しい風が吹くのを感じました（ドメイン駆動設計そのものはだいぶ前からありますが）
これには、ドメイン駆動設計に関してを記した様々な実践書籍や入門書籍の貢献がとても大きいと思います。先人たちの知恵や知識のおかげでセンスや才能がない自分でもドメイン駆動設計についてある程度理解し現場でなんとなく実践することができました。
加えて、ドメイン駆動設計をやるにあたって真摯に向き合ってくれたチームメンバーの方々にとても感謝します。ありがとう。

最後に、コメントにて実体験や優しめのマサカリお待ちしております！

参考書籍