dddでの特定の機能の設計

Question

特定のドメインに対応する文字列パーサーは、ユーティリティまたはドメイン/値オブジェクトと見なす必要がありますか？

例：ユーザーが金融商品の検索リクエストを送信します。たとえば、「OMX KRエクイティ」このような文字列をプロバイダに送信するには、解析してその正確な値（楽器名、市場コード、楽器の種類）にマッピングする必要があります。検索要求ファイルの構造は機器の種類によって異なるため、文字列が解析された後で、機器のタイプをデータベースの既存のタイプと照合する必要があります。存在しない場合、検索要求を提出することはできず、ユーザーはそれに応じて応答を受け取る必要があります。

（ユーザーが検索リクエストを送信すると、アプリケーションがリクエストファイルを生成してFTP経由で外部プロバイダに検索リクエストを送信します）時間リクエストが満たされてからフェッチされてからFTPに保存され、データベースに保存されるので、検索要求に対して即座に応答はありません。）

このロジックを配置する適切な場所を見つけることはできません。通常、SearchRequestエンティティ内の値オブジェクトですが、データベースに対して検証する必要があるため、問題が発生します。

また、静的なソリ​​ューションの導入を避けようとしています。なぜなら、テストが難しくなると思われるからです。特にドメインロジックとみなされている場合は、ユーティリティ、ヘルパーなどの静的メソッドに属するべきだとは思わない。

dddによると、この問題を解決する正しい方法は何でしょうか？

Answer 1

特定のドメインにcorespondsストリングパーサは ユーティリティまたはドメイン/値の対象として考慮されるべきですか？

それはコンストラクタでフォーマットを検証しますValue objectでなければなりません（正規表現を使用して、たとえば：[A-Z]{3}\s[A-Z]{2}\s[a-zA-Z]{1,}）、それは、この文字列の三つの部分のための3つだけのゲッターがあります：getName():string、getType():string、getCode():stringを。このクラスの名前をInstrumentQueryにします。 only one responsability：文字列を検証+解析します。

検索要求ファイル構造は、機器の種類に依存するため、 文字列が解析されます後に楽器の種類は、データベース内の 既存のタイプと照合する必要があります。

は、「データベース内の既存の型と照合」 SearchRequest aggregateにコマンドをディスパッチする前に、検索コマンドを受信 Application serviceで行われます。ワイドワールドの既存のドメインのほとんどでは、何らかの種類の query methodが検索されますが、 SearchRequestは Aggregateです。この集約は submitQuery(InstrumentQuery instrumentQuery) command methodです。

デザインによっては、InstrumentTypeはEntity（IDです）またはValue objectです。 Entityの場合、submitQueryはIDを受け取ることがあります。それは内部使用に依存します。いずれにしても、コマンドがSearchRequestAggregateに達する前に、その存在がRepositoryからロードしようとすることによってチェックされます。特に

それはドメインロジックと見なされた場合、私はそれが あなたが見ることができるように、2つの異なる検証を持って

などのヘルパー、ユーティリティとしての静的メソッドに属しているか、必要があると思ういけません。

1. SearchRequestのフォーマット：純粋ドメインロジックは、ドメインコード層の内部に、内部ValueObject留まります。
2. InstrumentType：アプリケーション層ロジックの存在。リポジトリからロードしようとするとチェックされます。