DDDは時間の無駄ですか？ [閉まっている]

StackOverflow https://stackoverflow.com/questions/810606

  •  03-07-2019
  •  | 
  •  

質問

グーグル＆quot; DDDはどのような用途に適していますか？」次の答えをくれました：

  

おそらく、すべてのソフトウェアアプリケーションの95％が＆＃8220; DDDの使用にはあまり適していません＆＃8221;カテゴリー。 （記事）

では、大騒ぎは何ですか？！？

私が取り組んでいるアプリケーションは、主にデータ中心である ですが、まだ適用されるビジネスロジックとルールが含まれています。 DDD技術の適用を開始するのは時間の無駄でしょうか？従来のデータアクセスレイヤー、POCOのモデル、およびビジネスロジックレイヤーを使用する方が良いでしょうか？または、別の言い方をすれば、DDDに代わる健全な代替手段は何ですか？

役に立ちましたか？

解決

DDDがプロジェクトに役立つと考える開発者の多くは、自分の仕事はコードを書くことだと思うというthinkに陥ります。そうではありません。開発者の仕事は機能を実現することであり、ソフトウェアを介して問題を解決することができます。これは、コードを書くことは開発者がしていることの始まりではなく、最後であるという結論になります。コードは、コードが実際に書かれる前のプロセス全体の結果です。

DDDはコードを記述することではなく、優れたソフトウェアを入手するための10段階のターンキープロセスではありません。コードを記述する前に、そのプロセス全体について、問題が何であるかについての洞察を得ることです/誰がどの情報ストリームに参加し、これらの要素がどのように見えるか、どのように互いに関連するかなどなど。実際、DDDの最も重要な部分は、ドメインの専門家と開発者の間の会話を可能にする言語を作成することです誤解なし。これはエバンスが語る「ユビキタス言語」です。実際には、コードが記述される前のプロセス全体が、推測されることのほとんどないプロセスになり、物事は明確で簡単です。 （それが目標です）。

「DDDが実際にどのように機能するか」という問題と「DDDでコードを記述する方法の例を教えていただけますか？」などは、この種の質問をする人々がコードの作成に焦点を当てているが、他のコードではなくそのコードを書いている理由がわからないという事実から来ています。 I.o.w .: DDDが、機能として記述しなければならないものを発見することであり、その理由がわかった場合、状況は適切です。そのコードをどのように書いているのかはあなた次第です。しかし、すでに述べたように、それはもはや最大の問題ではありません。それまでに、何を書かなければならないのか、そしてなぜそれを知っているのでしょう。

他のヒント

ご存知のように、5％は他のすべての95％よりも多くのお金を稼ぎます-それがDDDが存在する理由です。

特定の複雑で大規模なシステム用です。

申し訳ありませんが、Frans Boumaが言うようにDDDが単なる考え方である場合は、Persistence Ignoranceなどを推奨しません。これは他の人をやや劣っている開発者として退けています。

DDDに少なくともバイアスがある

PIは、アーキテクチャ上の選択です。それはもう考え方ではありません;それはすでにあなたに提供されているもので、ほとんどの場合、あまりにもあいまいな警告です。「すべてに適していない」」。

しかし、PI方式を採用するかどうかを決定すること自体が課題であり、彼がこれについて不安を感じている場合、誰か（「コーダー」）の名前を呼ぶことはできません。

MS Accessのようなインターフェースを全面的に備えたERPパッケージを使用してください：積算合計、自動更新列、100,000レコードのページレススクロールを備えたグリッド。明らかに、DDDのアプローチは、このアプリの使用方法を考えるのに適しています。しかし、何年も私は誰も見たことがありません-本でもオンラインでも、証拠に裏付けられた説明に加えて、実生活のコード例はもちろん、PIがこのユビキタスの状況をどのように対処したいのかを説明しました< strong>商用グレードのアプリとユーザーエクスペリエンス。

これについて宗教的になりたくない。 DDDおよびDALの支持者は過度に宗教的である傾向があり、一度噛まれたことがあるがオープンマインドな人を追い払う可能性があります。多くの人は、実際の体験（つまり、THINK）に立ち向かい、猫、車、基本的なOrder / OrdersItems（つまり貧しいCODE）だけで説教をサポートすることは望んでいません。

これは非常によく似た質問です： Web層がDALに直接アクセスすることを許可しますか？

すべてのプロジェクトでDDDを使用しています。小規模なアプリケーションでは、いくつかの概念が適用されませんが、サイズに関係なく、多くの側面がすべてのプロジェクトに適用できます。

DDDは、しばらく維持されるソフトウェアに関するものです。私にとって、これはドメインによって変わるアイデアを表現する必要があることを意味します。シンプルなアプリは、短い配信時間と短い実装時間に最適かもしれません。ただし、ソフトウェアを成長させる必要がある場合は、DDDの原則が非常に役立ちます。 DDDは前もって難しいかもしれませんが、ユビキタス言語と分離に関する懸念を理解すると、事態は容易になり始めます。

この記事をもう少し読むと、次のように表示されます：

  

DDDのあるアプリケーションの5％   ぴったり、非常にぴったりです。   これらの状況では、DDDが役立ちます   非常に堅いナットを割る。ここで、DDD   そのための特効薬かもしれません   あなたのマネージャーだけの狼男   デスクを指しています。

だからこそ、大騒ぎします。

  • アプリは主にデータ中心であるため、アーキテクチャは主に従来のものである可能性があります。

  • より多くのロジックと潜在的なドメインまたは値オブジェクトがある側面については、DDDのアイデアの一部を活用してコードを整理できます。

  • 一般的に、「サウンドの代替」は物事を可能な限りシンプルに保ち、有用な場合はDDDの概念を使用し、記事が不必要に複雑化しないようにすることです。

現在、同様のプロジェクトを開始しています。これは、データ操作と、よりロジック/アルゴリズム駆動型の領域が混在しています。同様に、プロジェクトに利益をもたらすDDDの部分を取り上げたいと思いますが、逆効果になる可能性のある領域でそれを強制しようとはしません。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top