0

MVC フレームワークを使用して Web アプリを作成しています。コントローラーとドメイン モデルの間にレイヤーを追加することを考えました。ドメイン モデルに特定のユース ケースに固有のロジックを配置することを避けるために、DDD ではアプリケーション レイヤーと呼ばれていると思います。コントローラーはこのレイヤーとのみ対話し、このレイヤーはドメイン モデルを使用して操作を調整します。このレイヤーは、ドメイン モデルに固有のユース ケースではないすべてのロジックをプッシュする、可能な限り薄く維持されます。このレイヤーに属するクラスを DomainCtrl と呼びます。

ログイン シナリオの例: モデル: LoginForm DomainCtrl: AuthCtrl UI: ui コントローラー

1.ui コントローラーがリクエストを受け取る 2.AuthCtrl のインスタンスを作成する 3.AuthCtrl が LoginForm のインスタンスを作成し、authCtrl に渡されたリクエスト データを入力する 4.LoginForm がログインを実行する 5.authCtrl が、この特定のログイン方法に固有の他のことを行う-> ui コントローラーにエラーを返します

これはアプリを整理する良い方法ですか?

4

2 に答える 2

1

あなたの質問

これはアプリを構成する良い方法ですか

非常に負荷の高い質問です。簡単な答えは「はい」ですが、より正しい答えは「場合によります」です。

簡単な答えから始めましょう。メイン アプリケーションが UI を認識しないようにすることは、通常は良い考えです。これは、さまざまな場所からアプリケーションを簡単に使用できることを意味します。DDD では、この外側の層は通常アプリケーション層と呼ばれます。主に、ドメイン、永続性、および依存する可能性のあるその他のリソース間の相互作用の調整を担当します。これにより、他のすべてを認識せずにドメインを中心に置くこともできます. これにより、適切に実装されていれば、ドメインのテストと保守が容易になります。

今、答えの「それは依存する」部分です。DDD は、アプリケーションを構築するための唯一の成功した方法ではありません。私のアプリが何をしているのか自問する必要があります。ドメイン固有のルールはたくさんありますか? 基本的なデータなどを取得して保存するだけですか? これらはすべて、アーキテクチャとテクノロジを選択する前に答える必要がある質問です。

DDD アプローチは一般的には良い方法であるため、おそらく間違いはないと思います。

*注: あなたの例は私には明確ではありませんが、UI の概念をドメイン/アプリケーションに流出させないように注意する必要があります。ログインフォームは完全に UI の概念であり、認証もある程度です。おそらく、アプリケーションにユーザーの詳細を返すようにさせることができますが、UI レイヤーは、ユーザーが続行できるかどうかを決定する必要があります。

于 2015-02-14T21:24:18.657 に答える
0

大まかに言えば、はい

ただし、最終的には、レイヤーを論理的に分離する「方法」に依存します。あなたのシナリオでは、アプリケーション層はありません。

  • AuthCtrl がドメインだと思いますか? AuthCtrl を作成したのは誰ですか? それはどの層に存在しますか？
于 2015-02-16T03:24:16.253 に答える