インフラストラクチャまたはドメインの責任が何であれ決めることはできません。ドメイン駆動設計：インフラストラクチャの懸念またはドメインの懸念？
ユーザーは、dateStart = 2016-04-12、dateEnd = 2016-04-15などのURLクエリで日付範囲を渡すことができます。その日付範囲に基づいて、これらの2つの日付の間にフィールドcreatedOnを持つエンティティのリストを返します。この作業を正しく行うには、2016-04-12を2016-04-12 00:00:00と2016-04-15から2016-04-15 23:59:59に変換する必要があります。この変換はインフラストラクチャの問題とみなされるべきですか（そして、リポジトリに置かなければならない、あるいはアプリケーション層かもしれません）、またはビジネス規則に従うべきです（そして、サービスやエンティティに入れなければなりません）？
この変換は、インフラストラクチャの問題（リポジトリやアプリケーションレイヤーに置く必要があります）やビジネスルール（サービスやエンティティに入れる必要があります）と考えるべきですか？
plalxで述べたように、DateRange/TimeIntervalそう自分自身で重要な概念であり、あなたのモデルに値型として表現されなければなりません。
取得したユーザー入力を受け取り、モデルで表される型で表現することは、アプリケーションの関心事です。
この制約を満たすエンティティのリストを見つけることは、リポジトリの関心事でなければなりません。その制約をリポジトリ契約で明示的にすることは有益です。これは、基礎となるストアで必要な機能を文書化するのに役立ちます。
私はUtilオブジェクト（クラス）を作成しますが、それはあなたのために変換メソッドを提供します。
最も深いレイヤー（何らかの種類のリポジトリ）でフォーマットを使用する方法を決める必要があります。その形式がアプリケーション層に表示されている形式と同じでない場合は、会話をどこかで使用するよりも（バックエンドAPIの先頭をお勧めします）、リポジトリ層などの内部で検証を使用できるようにしてください。同じように。
サービスクラスまたは一般的に使用されるすべての機能を持つライブラリクラスが理想的です。たとえば、この場合、formatInputDateと呼ばれる関数は、日付の書式設定に使用できる関数です。 –
これはデータ制約のようですが、アプリケーションのルールでは短いISOの日付形式が許可されますが、データベースでは長いISOの日付形式のみがサポートされるためです。したがって、それはデータアクセス層（またはそれらを使用する場合はストアドプロシージャ/ビュー）に入れなければならないデータベース関数です。 –
'DateRange'はかなり重要な概念のようです。私は、日付範囲の規則を適用する値オブジェクトとしてモデル化します。日付範囲の境界は、日付値によって定義されます。アプリケーションサービスは文字列を受け取り、 'DateRange'を作成します。 'DateRange'はリポジトリに渡されます。日付の書式は、リポジトリ内で発生します（日付ユーティリティメソッドへの委任）。 – plalx