問題タブ [ddd-service]

ddd のアプリケーション層はモデルを持つことができますか?

より明確に言うとcredential、システム内に、ドメイン層の外側にある認証プロセスに関連するエンティティがあります。このエンティティはどこにあるのでしょうか? 私はドメイン駆動設計の初心者です。

新しいサービスのハイレベルなデザインを作成しています。サービスの複雑さは、DDD を使用することを保証します (私は思います)。そこで、従来の方法でドメイン サービス、集計、リポジトリなどを作成しました。リポジトリはデータ ソースをカプセル化します。したがって、クエリはキャッシュ内のオブジェクトを検索できます。データベース内の検索に失敗すると、オブジェクトの作成に失敗します。REST必要な情報を取得するために外部サービスを呼び出します。これはかなり標準的です。私の同僚は、リポジトリを使用する開発者が API の実行に必要な時間を認識できず、その結果、API の実行時間を計算できないため、この方法でデータ ソースを抽象化することは危険であるという主張を提唱しています。その上に書いています。自分の呼び出しが呼び出しになることを知っていれば、コンポーネントの動作を別の方法で設定したいと思うかもしれませんREST。彼らは私が移動することを提案していますRESTリポジトリの外部で呼び出し、場合によってはキャッシュ戦略も一緒に呼び出します。彼らの言いたいことはわかりますが、リポジトリ パターンの背後にある全体的な考え方は、まさにこの種の情報を隠し、各コンポーネントにキャッシュ戦略とデータ アクセスを処理させないようにすることです。私の質問は、この懸念に対処するパターンまたはモデルはありますか?

HyperLogLog [ HLL ] を使用して、ドメイン サービスの冪等性へのアプローチを評価しています。

このアプローチの目的は、大量の役に立たない情報を保存することなく、冪等性を保証する一般的な方法を提供することです。時折の重複に対する許容度のみが必要です (1 通ではなく 2 通のメールを送信してください)。

私のシナリオでは、すべてのサービス リクエストは toHashCode 関数を持つメッセージ オブジェクトです。アルゴリズムは次のようになります。

1. リクエストを受信すると、ドメイン サービスは HLL[ S1 ] カーディナリティを計算し、それをC1として保存します。
   
2. リクエストハッシュ [ H ] がHLL [ S2 ] のコピーに追加され、カーディナリティがC2として格納されます。
   
3. C1 == C2の場合、リクエストは複製され、S2は破棄されます。
4. それ以外の場合、リクエストは処理され、ハッシュ [ H ] が HLL [ S1 ] に追加されます。

誰かが同様の解決策に遭遇しましたか? （ブルームフィルターのような）
この種のソリューションの欠点は何ですか？

アプリケーション サービスに関する私の理解では、アプリケーション サービスはドメインとユーザー インターフェイスの間を結び付けます。つまり、ドメインで操作を実行するコントローラーとして機能します。

アプリケーションに次のプロジェクト レイアウトがあります。

• ドメイン コア
• インフラストラクチャー
• サービス インターフェイス
• ウェブ UI
  • ビューモデル
  • ビュー
  • コントローラー
  • サービス (アプリケーション サービス)

私のService Interfaces嘘はWeb UIプロジェクトの外にあります。次に、Web UIプロジェクトで、サービス インターフェイスを の下に実装しますServices。

ただし、この構造には少し欠陥があり、これを実際に使用すると循環依存が生じます。このリンクのアーキテクチャをたどろうとしました: https://www.develop.com/onionarchitecture

特定のサービスについて、ビュー モデルを渡し、ビュー モデルに基づいてドメインで操作を実行し、更新されたビュー モデルを返します。このアプローチは間違っていますか？

アプリケーションサービスは本質的にビューモデルをパラメータとして取り、必要に応じてドメインとビューモデルの詳細を更新し、ビューモデルを返すという私の理解は正しいですか?

または

アプリケーション サービスは、C# のデータ型とドメイン モデルのみをパラメーターとして処理し、同じデータ型を返しますか? つまり、ビュー モデル内の情報を取得または設定しません。実際には、ビューモデルが存在することを知りません。

厳密な DDD アプローチからの最良のアプローチは何かを明確にする必要があります。

新しい SaaS アプリを構築していて、DDD の原則に従いたいと考えています。

アイデアをスケッチしている段階で、この問題に遭遇しました。人々が私に考えを与えてくれることを願っています。私はこれに必ずしも正しいか間違っているとは思わない。しかし、私はあなたの考えを聞くのが大好きです...

基本的に、Billing がどこに属し、どのように実装するのが最適かはわかりません。

ユーザーが請求インターフェースを認識する必要があるかどうかはわかりません。請求を実行するのはユーザーエンティティの責任ですか??

ユーザーエンティティがサブスクリプションを持っているかどうかを知るのは公平だと思いますが、それがどのように実装されているかはわかりません。

この段階では、ドメイン層が BillingInterace を指定し、実装がインフラストラクチャ層にあると考えています。(最初は Stripe を使用します)

請求サービスを作成し、ユーザー エンティティを渡して、ストライプで顧客アカウントを作成し、請求機能を実行しますか?

または、ユーザーエンティティにドロップされる特性をコーディングして、ユーザーが自分で請求できるようにします ($user->charge() など)。

それが理にかなっていることを願っています。このようなものについてオンラインでまともなガイダンスを見つけることができないので、いくつかのアイデアを投げかけようとしています.

ありがとう！！リー

次のアプリケーションには DDD を使用することを考えています。私はすでに多くの興味深い論文と回答を見つけましたが、私の問題の解決策を見つけることができません:

SOAがあります。一部のサービスがデータのマスターとして知られているアーキテクチャ。それは素晴らしいことですが、DDD でうまく使用する方法がわかりません。

データのマスターであるサービス「従業員」を考えるとEmployee、いくつかの単純な値 (名と姓、生年月日、住所) に対するクラッドです。私の新しいアプリは、それらの従業員に提供されるトレーニングを追跡する必要があります。だから私は の概念を持っています。a はParticipant、トレーニングとスキルのリストに加えParticipantて、同じ値を持ちます。Employee

「トレーニング」アプリケーションには、 を含む参加者のテーブルを含むデータベースがありparticipant_id、名前と姓を取得するために使用されるskillデータベースがあると想定できます。employee_id

私は正しいですか？

しかし今、どのコンポーネントを使用して「従業員」サービスを呼び出すことができますか? 私ParticipantRepositoryが参加者を取得したときに私が持っているのは名前です。それとも、Participantデータを使用する前にデータを完成させるのはアプリケーション サービスですか。または、必要に応じて従業員サービスを明示的に呼び出すことができますか?

どうもありがとう。