2017-07-29 6 views
0

新しいプロジェクトを開始し、ドメイン駆動型設計からいくつかの概念を実装しようとしています。私たちは、以下の層を持っていることを計画している:WebAPIのアプリケーションサービスコード

  1. Webインターフェイス(WebAPIの)
  2. アプリケーションサービス(ライブラリ)
  3. ドメインサービス(ライブラリ)
  4. データアクセスサービス(図書館)

私たちは、Webインターフェイスとアプリケーションサービスを統合することを考えています。したがって、私たちのwebAPIは、リポジトリ、ドメインモデル、およびドメインサービスと対話します。

これは問題ないですか、別のプロジェクトフォームアプリケーションサービスが必要ですか?WebAPIはアプリケーションサービスとのみ通信する必要がありますか?

おかげ

+1

粗いアプリケーションサービスがあると間違ってはいないかもしれませんが、私が必要となるまでは、これらの機能がなくても使い始める傾向があります。たとえば、SomeService.Find(id)と 'SomeQuery.Find(id) 'との違いについては、あまりにも細かいことがあります。:) –

答えて

2

HTTPは、アプリケーションサービスに到達するために潜在的に多くのアクセスポートの一つとして見られるべきです。 HTTPよりも別の通信チャネルを使ってアプリケーションに話す必要がないと確信できるのであれば、完全に別のアプリケーション層を持たないといいでしょう。

しかし、アプリケーションのニーズがどのように進化するかを予測することは非常に難しいと言えます。アプリケーション層をすぐに分離するために間接的な追加層を追加することはコストがかかりません(単なる委任です)。私はやります。