この分野の開発者からドメイン駆動開発について聞いた。彼は、それが要件の変化に対する特効薬であるかのようにそれを話しました。
wikiを読みました。まだ明確ではありません。実用的な用語で「3D」とは何ですか？現在、UMLクラス図が時代遅れになっているのは本当に驚くべきことですか？
この分野の開発者からドメイン駆動開発について聞いた。彼は、それが要件の変化に対する特効薬であるかのようにそれを話しました。
wikiを読みました。まだ明確ではありません。実用的な用語で「3D」とは何ですか？現在、UMLクラス図が時代遅れになっているのは本当に驚くべきことですか？
回答:
まあ、まず第一に、あなたが言及するウィキペディアの記事は非常に良いとは思いません。それは主にドメイン駆動設計に付随するものの多くを参照しており、実践について誰にも啓発することはほとんどないからです。
しかし、ドメインドリブンデザインを真剣に考えている人（通常、3Dではなく、DDDの価値があります）として、私はいつも、DDDの基本は明らかだと感じました。エヴァンスの本。しかし、これは一連のパターンと実践であるため、詳細を説明せずに、それが何であるか、および利点が何であるかを3文で要約するのはそれほど簡単ではありません。どの詳細がどの人に共鳴するかは、非常に異なっているかもしれません。10年前には、私はまったくその点を見ていなかったでしょう。
DDDは特効薬ではありません。賢明に行うと、ソフトウェアを構築する職人のようなアプローチをとり、開発チームとソフトウェアを構築するビジネスの間の認知摩擦を減らす必要性を認識することです。最も重要なプラクティスの1つは、ソフトウェアチームとビジネスチームが使用するドメインボキャブラリーが可能な限り一致するレイヤーを持つことです。解決しようとしているビジネス上の問題を理解するようになると、この層を繰り返し構築します。ビジネスロジックがこの層で適切にエンコードされ、それらのシステムとの相互作用をインターフェイスに含めることにより、エンタープライズアプリケーションが通常持つすべての複雑な依存関係から分離されると、実際のドメイン層で使用される言語は最終的にかなり簡潔で、明白で、読みやすくなります。
私がほとんどのエンタープライズソフトウェアで見た形を考えると、実際には、DDDは銀の弾丸のように聞こえるかもしれません。表面的には些細なコード変更の副作用が何であるかはわかりませんが、適切にファクタリングされたドメインレイヤーは独立してテストおよび検証できます。しかし実際には、DDDはシステムが単独で存在することはめったにないことを認めています。DDDには、レガシーシステムの対処パターン（破損防止レイヤー、境界付けられたコンテキスト、カップルなど）が含まれています。
疎結合の規律を含むオブジェクト指向設計を実践し、ユニットテストをかなり宗教的に実践し、コードを容赦なくリファクタリングし、システムの構築中にドメインの専門家と協力すると、本質的には次のような結果になります基本的に、ドメイン駆動設計の支持者が話していること。
Evansの本で説明されているいくつかの特定のパターンがあり、ほとんどがエンタープライズソフトウェア開発に適用され、一部はかなり普遍的な原則ですが、本質的に、DDDは時間の経過とともに技術的負債の蓄積を削減できる実用的なソフトウェア開発アプローチです互いに同じ言語を話すことができるため、顧客をより幸せにし、お互いをよりよく理解することの利点により、より効果的なソリューションを提供します。
免責事項：この質問に重複マークを付けた後、この回答を追加しました。私は同意しませんが、ここにいます。:-)
ドメイン駆動設計は、価値が高く複雑なドメインでソフトウェアを設計することを目的としています。
これは、エンタープライズソフトウェアを構築するための別のアプローチに変わります。学習が多すぎるため、最も重要な結果は、最初の段階で適切なソリューションに到達できないことです。
または両方の組み合わせ。
どちらの方法でも、頻繁にソフトウェアを書き換えるための優れたソフトウェア基盤が必要になります。それが、ドメインモデルパターンに関するパターンの特定のセットに本が重点を置いた理由です。2004年で最も合理的な組み合わせでした。
ただし、OOPと戦術パターンは最も重要なものではありません。革新的な方法で優れたソフトウェアを構築するには、技術的な習熟が必要です。しかし、それはレシピの1つの成分にすぎません。他人？