議論のために、私には、2 つの異なる用語が実際には同じことを言っているように思えます。この 2 つの設計アプローチの間に具体的な違いはありますか?
16358 次
6 に答える
29
ユースケースは、ユーザー、アクション、およびプロセスに焦点を当てています。システムが提供するものを抽象化したビューを誰もが見ることができるため、これはビジネスの観点からは素晴らしいことです。
DDDは、問題を解決するソフトウェアの作成に重点を置いています。'誰がこれを解決できますか? ' および '彼らはどのようなプロセスをたどりますか? 'その後に来てください。
DDDは、設計プロセスの早い段階で核となる問題に実際に到達し、ソリューションを構築するのに役立ちます(つまり、エンティティ、値オブジェクト、リポジトリ、ドメイン/アプリケーション/インフラストラクチャ サービス、境界付けられたコンテキスト、仕様などを特定します)。
ユースケースはこれにまったく対応していないか、開発を管理する方法（腐敗防止レイヤー、個別の方法など）
私の経験では、DDD は柔軟性が高く(要件を変更する人はいますか?)、ユース ケースの基盤を提供します。ドメイン モデルを配置したら、ドメイン モデルに接続するコントローラー/ワークフロー エンジン/UIを使用してユース ケースを実装できます。ドメイン モデルを構築するだけで、ビジネス要件のギャップを特定することがよくあります。
また、数年前に Ivar Jacobsen の講演に参加したことがありますが、DDD はアジャイルに適しているとも言えます。
于 2010-07-09T05:51:35.737 に答える
10
私にとって、ドメイン駆動設計 (DDD) はより「すべてを包括する」ものです。ユースケースは、特定のビューに焦点を当てた単なるツールです。何かが刺激にどのように反応し、行動要件をキャプチャまたは文書化するために使用されます。
私にとって、「ドメイン」という用語は、特定の問題領域に関連するすべての概念のより広い視野を暗示しています。
ドメインの部分がどのように相互作用するか、特に刺激にどのように反応するかを説明するときは、ユース ケースを使用できます。
アプローチに関する限り: ユース ケースは4+1 Architectural View Modelの「追加」ビューですが、それ自体は設計アプローチではありません。
もう 1 つの違いは、DDD がオブジェクト指向のモデルまたはシステムと非常に密接に結びついていることが多いことです。このようにして、DDD は (とりわけ) システムの構造をキャプチャ/表現します - ユースケースでは行わないことです。
于 2010-07-04T08:44:57.790 に答える
5
これは私の経験に基づく個人的な解釈です。
ユースケース駆動型設計では、ユースケースをツールとして使用して、エンティティ、インターフェース、対話メッセージ、および特定のビジネス操作がどのように行われているかに関するワークフローを発見します。これは、要件を収集または理解し、いくつかの初期設計を確立するために、より多くの分析または設計段階でよく使用されます。一方、DDD は、ドメイン エンティティとコンテキストに重点を置いた実装を重視しています。モデル (クラス、インターフェイスなど) を定義し、その境界、集約、操作、およびドメイン固有のロジックを定義するという点で、ユース ケースよりも詳細に焦点を当てています。一般に、実装時にそれらにアプローチする方法については、いくつかの標準的な慣行に従います。
DDD は、会計、エンジニアリングなどの特定のドメインを対象とするプロジェクトを扱っている場合に適しています。ビジネスのモデルの一部またはほとんどが複雑な相互関係と具現化されたロジックを持つ可能性があると予測できます。ユースケース駆動型設計と DDD のどちらを選択するかは、ドメインの専門家の可用性にも依存します。ビジネス ニーズを持つ利害関係者がいる場合 (ドメイン エキスパートへのアクセスが一部しかない場合)、DDD と比較すると、ユース ケース駆動型の設計が適しています。プロジェクト。
個人的には、ユースケース駆動型の設計から始めて、DDD アプローチを使用して詳細設計と実装に取り組むことができるいくつかのプロジェクトで、両方が相互に補完できると思います
于 2010-07-09T01:40:34.990 に答える
4
製品のクライアントが1 つしかなく、クライアントが製品で解決する必要があるすべての問題についてすでに説明している場合、ユース ケース駆動型のアプローチはうまく機能します。これは、一般的にサービス指向の企業で可能です。同じ製品に対して複数のクライアントがあると、管理が難しくなります。これは、一般的に製品開発会社で発生します。そのような場合(製品主導型企業) DDDが役に立ちます。DDDを使用して製品を開発します（ベースと呼びます）。次に、新しいクライアントのすべてのユースケースが適用可能かどうかを確認し、そうでない場合は、クライアント固有の変更のためにベース上にレイヤーを形成します.
于 2010-07-17T08:00:38.590 に答える
4
ドメイン駆動設計は基本的に、考えられるすべてのユースケースを事前に知っているかのように振る舞おうとします。定義上、「問題」ドメインは、そのドメインのメンバーと見なされる特定の問題のセットです。
于 2010-07-11T23:04:43.340 に答える
3
私はこれについて専門家ではありません。これらの用語はあいまいで、人によって意味が異なる場合があります。しかし..
ドメイン設計とは、既存のシステム (紙ベース、マニュアルなど) があり、ソフトウェアがシステム内の実際のエンティティをモデル化する場所であると言っていました。したがって、図書館システムでは、図書館を見て、本、棚、戸棚、部屋があることがわかります。それに基づいて、ソフトウェアの実際のドメインをモデル化します。
ユースケースでは、「何をしようとしているのか」から始めます。ユースケースでは必要ないため、モデルに別の部屋は必要ないかもしれません。これにより、システムが単純になります (エラーが発生しにくくなります) が、「現実世界」をモデル化していない場合は、ある程度の柔軟性が失われます。
于 2010-07-23T09:20:52.967 に答える