DDDの質問
Qiita FMのnrsさん回で、雰囲気に合わないような長い質問だったのですが、
質問が読まれました！
質問内容は「小規模のプロジェクトではドメイン駆動設計のメリットを感じないのですが、どのような規模でメリットが感じられるようになりますか」
質問にお答えいただいたのは次のような内容でした。
- 「ドメイン駆動設計」とはそもそも何を意味しているか？
- ソフトウェア開発全般か、レイヤードアーキテクチャか
- レイヤードアーキテクチャでは、クラスを分けることでテストが単純化される
- クラスが増えることで面倒な部分は、スケルトンを作るツールを準備する
確かに、と思いました。
質問が読まれて気が付いたのは、自分も「ソフトウェア開発全般とレイヤードアーキテクチャ」のどちらを指しているかが分からなかったところがあります。
そこまで難しくないものが階層分けなどで複雑化したわりに、その実装の方針などで議論が多数生まれ、本来のメリットであるテストの容易性よりも議論が積み重なったことにより、メリットを感じされなくなったことで、あのような質問になったように思います。
DDDが難しかったこと
自分にとってはDDDが難しいと感じたところは、DDDが大きな括りでの「設計」だということです。
開発で、SEとプログラマーが分かれている場合などは、「システムの設計」と「実装上の設計」も担当が分かれていて、プログラマーは後者の担当になるかと思います。
DDDでは、これらの二つの設計を包括して「設計」と呼んでいるように読めました。
ですから、例えばプログラマーに「DDDでやります」というだけで、できるものでは無いように感じました。
従来の開発よりも時間が必要かもしれない
DDDで開発を行う場合、「DDDをやると決めた側」が、そのチームのメンバーに設計やアーキテクチャをうまく伝搬、伝承する必要があるように思いました。
また、モデリングなども、事前に相談する時間がなければ、プログラマーが単独でモデリングした場合など、そのモデリングが違うということで議論になるかもしれません。
また、どのようなアーキテクチャを採用していて、どういう構成が良いか、どういう方針で実装を進めるか、という、プログラマー側にお任せで行っていたことも、全体での相談が必要で、何らかの資料や詳細な説明などでカバーすることも必要になりそうです。
そして、理解する時間も必要かもしれません。アーキテクチャも人によって解釈が異なることもあります。
例えばMVCのようなフレームワークであれば置くディレクトリやクラスの命名規則がある程度決まっていてブレにくいですが、DDDはそうならないかと思います。
一方でチームを支えるリーダーのような人が優秀で、相談への対応と、どのような設計をするかという議論がうまければ、柔軟性に優れたものになりそうです。
戦術的DDDは重宝しそうに思いました
DDDが難しい一方で、プログラマーが単独でも取り入れられる「戦術的DDD」は保守性という意味でも、後で議論が発生しないという意味でも良さそうに思いました。
ユニットテストがしやすくなるのと、ロジックがドメインモデルにまとまることによって仕組みの理解がしやすくなるのはうれしいように思いました。
まとめ
結局のところ、分厚い本がたくさん出ているという意味でも、DDDはそこまで簡単にはならないし、DDDで開発するチーム全員が優秀な人とも限らないようにも思います。
一方で世の中のニーズもビジネスも高度化、複雑化しているので、サービスの保守にはDDDのような手法や技術が欠かせないようにも思いました。
そのような意味ではDDDを分かりやすく伝えてくださる先人の方々には感謝が絶えません。
（まとめ方がわからなくなったのでここで終わります）