![](\"//ws-fe.amazon-adsystem.com/widgets/q?_encoding=UTF8&ASIN=B00GRKD6XU&Format=_SL110_&ID=AsinImage&MarketPlace=JP&ServiceVersion=20070822&WS=1&tag=oshimayuki0d-22&language=ja_JP\")
![\"\"](\"https://ir-jp.amazon-adsystem.com/e/ir?t=oshimayuki0d-22&language=ja_JP&l=li1&o=9&a=B00GRKD6XU\")
チームで「この開発は DDD でやろう」と言ったとき、「DDD」は同じ意味で使われているでしょうか ?
\n人によって「DDD」という言葉の理解は違うと思います。
\nこの記事には、何が DDD で、何が DDD でないか、自分の考えをまとめました。
\nなお、この記事では
\nと略すことにします。
\nまずはじめに、DDD の世界に登場する概念を分類してみました。
\n![\"DDD\"](\"/media/DDD.png\")
図の通りですが、DDD に登場する概念は大きく「戦略的設計」と「戦術的設計」に分かれます。
\nさらに、戦略的設計は「思想」と「システムの分割・結合」の話、戦術的設計は「レイヤー構成」と「ビジネスロジックの実装方法」の話に分かれます。
\nこれらの概要を順に説明していきます。
\n![\"DDD-strategic-design\"](\"/media/DDD-strategic-design.png\")
戦略的設計は、具体的な細かいテクニックである戦術的設計よりも大局的な話です。
\n※ 図にも書いていますが、システムの分割・結合についての話を「戦略的設計」と呼ぶ場合もあるようです。
\nDDD の思想についてこの記事では詳細に立ち入りませんが、めちゃくちゃざっくり言うと、「みんなでユビキタス言語を使ってドメインエキスパートと話して、ドメイン知識をそのままソフトウェアで表現しろ」みたいな話です。
\n私の理解では、この思想が DDD のコアであり、これが抜けている場合は DDD とは呼べないと思います。
\n戦術的設計だけを使うことを「軽量 DDD」と呼ぶことが多いですが、思想が抜けている場合も「軽量 DDD」と言ってしまっていいかもしれません。
\n大きなシステムをどこでサブシステム (今風に言うとマイクロサービス) に分割し、どのように結合するかという話です。
\nシステムをどこで分割するかはとても難しい話だと思いますが、IDDD 本には、「ユビキタス言語に注目して、言葉の意味が変わったらそこが境界だ」といったヒントが書かれていたりします。
\nまた、腐敗防止層や共有カーネルといった、システムの結合方法についての論点もあります。
\n![\"DDD-tactical-design\"](\"/media/DDD-tactical-design.png\")
戦術的設計は、1 つのアプリケーションを具体的にどう実装するかというテクニックの話です。
\nDDD の話になったときにまず最初に出てくるのが戦術的設計ですが、戦術的設計だけを使うのは「軽量 DDD」というアンチパターンとされることが多いです。
\nコアなロジックを持つドメイン層をいかに隔離するかという話です。
\nDDD 本では「レイヤードアーキテクチャ」が、IDDD 本では「ヘキサゴナルアーキテクチャ」が紹介されていますが、「オニオンアーキテクチャ」や「クリーンアーキテクチャ 」を採用しても構いません。
\n要するに、ドメイン層をどうやって分離するかというパターンがいくつかあって、どれを採用するかという話です。
\nEntity、Value Object、Aggregate などを使って、ビジネスロジックをどう実装するかという話です。
\nこれは、いつでも必ずこう実装しろという話ではありません。
\nビジネスロジックの実装には
\nの大きく 2 つがあります。
\nDDD の文脈で説明されるのはドメインモデルパターンで具体的にどう実装するかという話ですが、どちらのパターンを採用すべきかは状況次第です。
\nDDD であっても、コアドメイン以外はトランザクションスクリプトで構わないということもよく言われます。
\nDDD のコアは「みんなでユビキタス言語を使ってドメインエキスパートと話して、ドメイン知識をそのままソフトウェアで表現しろ」みたいな思想にあると思います。
\nとはいえ、戦術的設計が身に付かないまま思想の話をされても具体的に実装するか想像できないと思いますし、まずは戦術的設計から挑戦するのも悪くないと思います。
\n私は戦術的設計を使ってみただけでも様々な悩みに遭遇し、その悩みを解決するために Aggregate や CQRS といった要素が必要だということに気付いたとき、自分が一歩スキルアップした気持ちになりました。
\n私は DDD でやれと主張するつもりは全然ないのですが、思想として面白いですし、設計力を高める上で参考になる要素が非常にたくさんあるので、勉強する価値は非常に高いと思います。
\n書籍
\nWeb
\n","fields":{"slug":"/posts/domain-driven-design-concepts","tagSlugs":["/tag/ddd/"],"autoRecommendPosts":["ddd-books","483997599X","application-architecture-books","what-is-service-class"]},"frontmatter":{"date":"2020-07-07T12:09:57.839Z","description":"DDD に登場する概念は大きく「戦略的設計」と「戦術的設計」に分かれます。さらに、戦略的設計は「思想」と「システムの分割・結合」の話、戦術的設計は「レイヤー構成」と「ビジネスロジックの実装方法」の話に分かれます。","tags":["ddd"],"title":"「ドメイン駆動設計 (DDD) とは？」を戦略的設計・戦術的設計に分けて理解する","socialImage":null,"recommendPosts":["https://www.kanzennirikaisita.com/posts/ddd-books","https://www.kanzennirikaisita.com/posts/application-architecture-books","https://www.kanzennirikaisita.com/posts/software-developer-books-index"]}}},"pageContext":{"slug":"/posts/domain-driven-design-concepts"}},"staticQueryHashes":["251939775","3942705351","401334301"]}![](\"//ws-fe.amazon-adsystem.com/widgets/q?_encoding=UTF8&ASIN=479813161X&Format=_SL110_&ID=AsinImage&MarketPlace=JP&ServiceVersion=20070822&WS=1&tag=oshimayuki0d-22&language=ja_JP\")
![\"\"](\"https://ir-jp.amazon-adsystem.com/e/ir?t=oshimayuki0d-22&language=ja_JP&l=li1&o=9&a=479813161X\")