little hands' lab

ドメイン駆動設計を布教したい

新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD]

ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か
ドメイン駆動 + オニオンアーキテクチャ概略

以前こちらの記事でアプリケーションアーキテクチャについて書きました。
こちらの記事では比較的ネタ元に忠実な解説をしたのですが、実際これに基づいて人にレイヤの説明をした際、依存性の逆転部分や円形で表現する部分がなかなか伝わりにくいことがありました。

そんな中で、所属プロダクトで新卒含めて大規模なリニューアル案件でDDDを採用することになり、新卒にも伝わるように説明をする必要性が生じました。
結果、新卒にも伝わり、運用が割と回る説明が見つかったのでご紹介したいと思います。

アプリケーションアーキテクチャ全体図

f:id:little_hands:20190726070231p:plain

とにかく、何か説明する際はこの図を常に傍に置き、一方通行の依存性を徹底したい、という話をしています。
何かについて議論をする際は、 「それはどの層の責務なの?」 という話をして、この図を元に「ではここに書かないといけないね」 という話をしています。

特に、ドメインモデル図にドメインの振る舞いを書いたあと 「この知識はUseCaseではなくDomain層に書きたいから、UseCaseに書いたらリファクタしよう」 ということは繰り返し伝えています。(UseCaseレベルのテストがあればあとはなんとでもリファクタできます)

徐々に伝わってくると、「これはドメインの知識なのでドメイン層に・・・」という会話が徐々に生まれてきてくれました。

(オニオンアーキテクチャとか、細かい話をするのは一旦やめました。笑)

以前の図との変更点

参考までに書いておくと、

・ApplicationServiceという呼称をUseCaseに変更した ・Infra層からDomain層への依存を実装の矢印で表現した
・Domain層をModelとServiceに分けるのはやめて一つにした
・登場要素をマッピングした

あたりが変更点です。

ApplicationServiceという呼称をUseCaseに変更した点については、「これはApplicationの関心ごとだよね」と言ってもApplicationが多義語すぎて人によって解釈がブレてしまったのに比べて、「ドメインの知識はDomain層に、ユースケースの実現はUseCase層に」という説明の方が伝わりやすかったためです。なお、ApplicationServiceは元々オニオンアーキテクチャの呼称、UseCaseというのはCleanArchitectureの呼称なので、ここだけはCleanArchitectureのエッセンスを取り入れた形になります。

Infra層からDomain層への依存を実装の矢印で表現した点に関しては、やはり以下の図では依存の形がイメージしにくかったためです。

f:id:little_hands:20181210195046p:plain:w400

これで何を指すのかがだいぶ一目で伝わりやすくなりました。

後からの補足として、依存関係逆転の説明

依存性逆転の法則については、実装を少ししてイメージが湧いた段階になってから、こんな説明をしました。

f:id:little_hands:20181210192908p:plain

f:id:little_hands:20181210193156p:plain

デメリットの

・DB変更のたびにEntityやUseCaseを変更する可能性がある
・DBの都合に引きずられた実装になる

あたりについて、新しいアーキテクチャの実装イメージが湧き、そうではないアーキテクチャでの苦しい経験が思い出されるようになると、「確かに〜」と納得してもらえるようになりました。

使い道

これを見てすぐにDDDの実装ができるようになる訳ではありませんが、議論のベースに可視化された一枚絵があるのはとても便利に感じます。そう言った使い身としてでもお役に立てると幸いです。

終わりに

WEB+DB PRESS 2019年10月号にて、「体験 ドメイン駆動設計 モデリングから実装までを一気に制覇」という特集を書きました。よろしければそちらもご覧ください。

TwitterでもDDDの話をつぶやいてるのでよろしければフォローしてください。記事に関するご質問もお気軽にどうぞ!

松岡@DDDブログ書いてます (@little_hand_s) | Twitter