Shiroichi Blog

日々のログ。ソフトウェア設計とねこが好き

「過大評価されるDDD(ドメイン駆動設計)」を読んで

「過大評価されるDDD(ドメイン駆動設計)」の記事(以下、記事)を読んで、色々と思考を広げていたので言語化して整理してみる。

itnews.org

記事の全てに対して言語化をすると大変なので、筆者が一番伝えたいであろう最後の2段落を記載しつつ議論を広げてみる。

私たちは独自の言語を発明できるし、発明すべきであるというこの概念は、単純な多くのDDD使用者が考えているよりもはるかに重要です。DDDの専門家はこのことをよく知っていて、DDDの資料を最終結果ではなく出発点として見ていると信じたいです。しかし、もしあなたが既存のDDD用語の決まりきった定義を使って、この既存の構造の中に問題を押し込もうとしているだけなら、あなたの設計者としての人生は非常に悲惨なものになるでしょう。

DDDをあなたのツールセットの一部にして、そこで終わりというのはいけません。DDDの先には人生があるのです。すべての優れた設計がドメイン駆動型である必要はありません(必ずしもDDDという意味ではなく、常にドメインによって駆動されるべきであることは認めますが)。DDDの専門家でなくても、良いシステムを設計することはできます。

とても深い共感を得た。個人的な意見として人間は経験に基づくと思っているので、DDDの専門家でなくともソフトウェア設計という分野に対して向き合った経験が豊富であれば良いシステムを設計できると思う。

だとすると、DDDはどのようなモチベーションで扱うべきか。

自分なりの結論としては、「コミュニケーションというプロセスにいかに重きを置くか」ということになると思う。

例として、チーム開発ではない個人開発であれば、「良いシステムを設計できる」という結果が重要で、結果に至るまでのプロセスにコミュニケーションは発生しない。

↑個人開発であっても「現在の自分」と「未来の自分」にコミュニケーションは発生するので、この例えは良くないかもしれない。

「誰かに伝える」もしくは「誰かから伝えられる」プロセスがなければ共通言語(ユビキタス言語)は有用ではなくなる。と考える。


ちょっと話は変わるけど、「DDDはソフトウェア設計におけるユビキタス言語」という話を聞いたことがある。

Eric Evansさんはソフトウェア設計というドメインにおけるユビキタス言語を自分のようなソフトウェア開発者に提供してくれている。

がしかし、ソフトウェア設計というものは正解がなく、ソフトウェアそれぞれに異なる道がある。

つまり、ソフトウェア設計というドメインには各ソフトウェアごとに異なるコンテキストが存在するので、各ソフトウェアのコンテキストにとって最良なユビキタス言語を模索するべきであると考える。

最後に記事に対する解釈を自分なりにまとめてみる。

DDDはあくまでEric Evansさんが自分たちに提供してくれたもの。

提供されたものをただ真似するのではなく、自分の設計(人生)は自分で決めなければいけない。

自分の人生は自分で選べ。

最後はかなり強気な意見になったけど、記事の筆者が伝えたいことはそういうことなんじゃないかと思った。