3

これは、DDD についてしばらくの間私を悩ませてきたことの 1 つです。複雑なモデルがあり、技術者と非技術分野の専門家の間で多くのやり取りが必要な非技術ビジネス ドメインを扱う場合、このアプローチの利点がはっきりとわかります。

しかし、問題の「ドメイン」が技術的なものである場合はどうでしょうか?

たとえば、状況 A) は、Web スタートアップを取り上げます。彼らが非常に複雑なこと (Facebook のクローンなど) を達成しようとしていると想像してみてください。ただし、ほとんどすべてのスタッフが技術者です (または、少なくとも技術的な理解が深まっています)。

状況 B) 同様の状況ですが、野心的ではないプロジェクトで、1 人の開発者がエレガントなアーキテクチャで何かを作成しようとしています。

私は人々が何を言わなければならないかを聞くことに本当に興味があります. 私が本当に理解しようとしているのは、DDD の利点がどこにあるのか、どのような欠点があるのか​​、そしてどの時点で一方が他方を上回っているのかということです...

4

3 に答える 3

9

DDD is really just an elaboration of the design pattern Fowler calls Domain Model in Patterns of Enterprise Application Architecture. In that book, he compares Domain Model to other ways of organizing code, such as Transaction Script, but it is clear that he prefers Domain Model over other alternatives for all but the simplest of applications. I do, too.

DDD simply expands greatly on the original concept of a Domain Model and provides tons of guidance on how we should analyze and model our domain in a way that will be beneficial to ourselves as developers.

If the Domain in question is complex, then a Domain model (and hence DDD) is a good choice. It doesn't really matter whether the Domain is business-oriented or more technical in nature. In his book Domain-Driven Design, Eric Evans starts by describing how the DDD techniques helped him model a Printed Circuit Board application. That is surely a technical Domain, if any!

In my current work, we are using DDD to model an application that deals with Claims-based identity - another very technical Domain.

DDD is really just about dealing with complexity in sofware, and this is also the subtitle of Evans' book: "Tackling Complexity in the Heart of Software."

于 2009-08-14T08:19:38.560 に答える
0

私はあなたに本当に良い答えを持っていませんが、DDDに興味を持っているDDDの部外者としての私の観点から、技術ドメインの概念/ドライバーがファーストクラスの概念としてDDDの会話に忍び寄るのを見てきました。この良い例は、一部の人々が技術的/インフラストラクチャに制限されたコンテキストを提唱していることです。私が考えることができる最も良い例は、Greg Youngのアーキテクチャであり、彼は制限されたコンテキストを読み取り、トランザクションは別の制限されたコンテキストを書き込むと考えています。一般に、このようなものは「ドメイン構造」だと思います（私の用語...実際のDDD用語を削除する必要がある場合は許してください）。これは、現実の世界では何かをモデル化していないが、完全にフラッシュされたオブジェクトであるOOの世界のオブジェクトに似ています。

于 2009-08-16T01:21:51.450 に答える
0

Evans は、次の場合にドメイン駆動設計を使用することを提案しています。

Domain Complexity > Technical Complexity
  • ドメインがシンプルでも、多くの技術的な制限 (技術の選択、パフォーマンスの制限など) がある場合は、DDD を使用しないでください。
  • ドメインが複雑な場合は、DDD を実行し、ドメインをシステムのコアとして配置し、その他の問題 (永続性、パフォーマンス、テクノロジの問題) を外に移動します。
于 2009-08-14T14:51:26.473 に答える