11

ここや他のフォーラムで尋ねられる多くの質問に対して私が目にする一般的な反応の1つは、「そのためにDDDを実行する必要はありません。その単純なCRUDアプリケーションであるDDDは過剰設計です」のようなものです。

私はDDDを初めて使用しますが、DDDには、アプリケーションがDDDを義務付ける複雑なenufであるかどうかに関係なく、普遍的な魅力があり、全面的に使用できる要素がたくさんあると思います。たとえば、アプリケーションの階層化、DDDが認識するさまざまなアーティファクトなどです。基本的なモデルと確かに貧血のモデルから始めて、可能な限り純粋にするために作業/リファクタリングすることができます。

このアプローチは良いと思いますか？
それとも、DDDを採用するかどうかという点で、すべてのアプリケーションの設計に基本的な選択があると思いますか。これは、一種の「全か無かの」選択です。

UPDATE （以下のhughのコメントに応じて、より多くのコンテキストを提供するため）
  既存のRuleEngineの種類のアプリケーション、基本的にはCRUDといくつかの検証、不変条件、そして展開プロセスを中心にWebアプリを構築しています。ルールの作成とセマンティックチェックは、CRUDの一部として呼び出すスタンドアロンのコードによって実行され、そのセマンティック固有のロジックはコードに含まれていません。このアプリケーションにDDDを使用しようとしていますが、DDDパラダイムに適合するほど複雑ではない可能性があります。ドメインにユビキタス言語が定義されていません。つまり、言語は、関係するエンティティのセットに名前を付ける以外に十分に専門化されていません。ドメインの専門家がエンティティの作成、編集、削除に関して話しているのを聞きました。

4

3 に答える 3

6

DDDはオールオアナッシングではありません。また、DDDで説明されているパターンの多くは新しいものではなく、至る所で見られます。Eric Evans（DDDブックの著者）は、それらを組み立て、必要に応じて形式化し、相互に関連させて設定しました。問題のあるスペースに合うものを自由に使用できます。

見落とされがちなこと：DDDは、分析パターンだけでなく実装パターンも記述します。分析パターンは、多くの（ほとんどではないにしても）アプリケーションではやり過ぎかもしれませんが、実装パターン（つまり、エンティティ、仕様、サービス）は、それほど複雑でないシナリオでも非常に役立ちます。

于 2012-08-07T13:48:20.060 に答える
4

要するに、

CRUDだけなら、気にしないでください。

一方で、

何かの次の状態が前の状態に依存する動作がある場合、DDDはおそらく検討したいものです。

于 2012-08-07T13:41:11.640 に答える
0

DDDアプローチは、戦略的パターンと戦術的パターンの2種類のパターンに基づいています。私見、あなたが確かに役立つことができるすべての場合に戦術的なパターンを自由に使用してください。ただし、一部のタイプのドメインでは、戦略パターンを使用するのはやり過ぎになる可能性があります。CRUDスタイルの考え方がモデリングプロセスに悪影響を及ぼさない場合は、確かにそれは必要ありません。

于 2019-10-24T12:24:15.877 に答える