記事のターゲット
- DDD（ドメイン駆動設計）に興味がある人
- DDD系の本読んだけど掴み所がないなと思った人
- 戦術的DDD（軽量DDD）を取り入れようとしている人
戦術的DDD（軽量DDD）とは
ドメイン駆動設計の文脈で語られる技術的要素のみを取り入れる設計手法です
Google検索などで引っかかる情報の多くは技術的要素の内容です
（過去記事でも部分的にまとめていますので興味があれば是非）
レイヤードアーキテクチャの視点
ValueObjectという考え方
Serviceクラスの意義と勘所
「技術的要素のみ？DDDってそういうものじゃないの？」と思ったかも知れません
DDDの本質は問題解決のための手法なので、技術的要素はその一つでしかないのです
完璧じゃなくても軽量だけでもいい
DDDに関わらず、プログラミング含めたテクノロジーも問題解決のツールの一つです
そのツールが万能になるとき、問題は即座に解決されて様々なメリットをもたらします
- 新しい事業を生み出すためのお金と時間を作る
- 単純作業をなくし、QOLの高い生活が送れる
- 人生の悩みを解決してくれる
- etc...
ただし、**ツールが万能に…**という点が難しいのはこの記事を読んでいる人なら理解していると思います
- レガシーシステムが意味不明でバグの採掘所になっている
- 技術レベルの乏しいメンバーが正しく動くコードを書けない
- etc...
せめて、「問題解決領域であるプログラミング部分を本質的な問題解決に集中できるように！！」と
考えた人たちがドメイン駆動設計の技術的要素のみを取り入れる軽量DDDを実践し始めています
うまくワークすると新しい知見が生まれる
戦術的DDDだけでもコードの信頼性・可読性があがり、テスタブルなコードを量産できるようになります
更に、業務をコードで表現できることでビジネス的な改善点が見えるなどのブレイクスルーが…！！！
だけどやらない
「じゃぁ、なんでみんなやらないの？」「あんまり世の中でやってる話聞かないよね？」のような意見はあるでしょう
銀の弾丸ではない
当たり前ですがソフトウェア開発にそれだけですべてを解決に導くようなツールや手法はありません
戦術的DDDに集中してしまうと本質的な問題にフォーカスできないと言った副作用が必ずあります
学習コストは高い
昨今、わかりやすい書籍が増えてきてかなりハードルは下がっていますがそれでもイメージのしにくい分野です
一人で開発しているならまだしもチームで開発する以上、全員のレベル感に差が出るのが必然です
その足並みを揃えないとどんなフレームも瓦解する未来が待っているでしょう
コードの制約が表現できない
今回、一番伝えたかったことでもありますが「戦術的DDDはコード的な制約を表現してこそ堅牢」になります
C#/Javaと言った静的型付けを前提とした言語でないとただの口約束・コードレビューでその担保をしなければならず
導入以降の運用にもコストがかかってきます
DDDを謳っている書籍もほとんどがC#/Javaと言った制約の強度を表現力高く書ける言語を例にあげられています
まとめ
- 戦術的DDDだけでも問題解決のフレームワークとして機能する
- 戦術的DDDが全うされると本質的な問題解決に集中できる
- DDDは銀の弾丸ではない
- 戦術的DDDだけでも学習コストは高い
- コードの制約が表現できない場合は運用が大変
なにか始める際の技術選定と同じように、ルールやチームフレームワークも導入・運用の難しさが伴うことが伝わればと思います