「App xには複雑なドメインがないため、多層アーキテクチャのオーバーヘッドを正当化できません。データアプローチを超えた形になっています。私は、その特性が、特定のアプローチで動くように強制するドメインのものが何であるか疑問に思っています。つまり、データの上のフォームのような単純な操作や、複数の層、ドメイン、DTOなどを構築する必要がある場合をどのように判断すればよいでしょうか。「データオーバーフォーム」アプリを認識すると、DDDアプリ
どちらのオプションも、ソフトウェアの作成に役立ちます。 （これは通常の容疑者 - あなたが直接的または間接的に支払うフレームワーク）
私は、パターンと実践を中間のどこかに置くことは可能だと思います。どこでソフトウェアを書いていますが、ほとんどの場合はあなたが既に快適なものに合っています。 （私はキーワードが「パターン」と強く結びついていると思います）。
よく知られているMVCの概念フレームワーク（およびその同族関係）が良い例です。これらはかなり一般的に扱うことができます。プラットフォーム、コンテキスト、個人的な好みに基づいてツールの支払いを選択する場合と選択しない場合があります。しかし、私は、MVCなどが圧倒されたり、圧倒される状況はあまりないと考えています（しかし、問題で提供されている2つのオプションのうちの1つが決定的に良いフィットになります）。
少なくとも、他の理由がなければ、短いライフサイクルのパターンやツール、スケーラビリティの問題につながる傾向があります（質問が直接言及します）。
これは決して確定的なものではありませんが、データに対するフォームは、主にビジネスルールでスリムで軽いドメインを指していると言えます。つまり、画面から一定のデータ構造にデータを入力するだけであれば、DDDアーキテクチャはそれほど重要ではないと思います。しかし、ドメインが複数の集約で構成されていたり、ビジネスルールが非常に重い場合は、おそらくDDDについて考えるべきです。
もちろん、私たちの世界のすべてのものと同様に、中間には多くの灰色の領域があり、最高の判断は決定を下すためのすべてです。
この質問はDDD message board
でお尋ねください。