データアクセスレイヤーは本当に私のドメインですか？
私はアーキテクトではありませんが、維持しているアプリケーションのアーキテクチャを表す図をまとめようとしています。
質問が1つあります（ただし、この分野でのトレーニングは行っていないため、図自体に関するコメントは歓迎します）。
私は基本的に、すべてのアプリケーションサービスが存在し、DTOが発生するレイヤーをドメインと呼んでいます。
データベースと実際にやり取りするレイヤーをData Access Layerと呼んでいます。その層には、アプリケーションサービスを経由する途中でDTOに変換されるエンティティも含まれます。
データアクセスレイヤーの名前を間違えましたか？
それをドメインと呼ぶ方が正確でしょうか？
現在ラベル付けされているドメイン、アプリケーションレイヤー、ビジネスレイヤー、またはサービスレイヤー（または何か他のもの）を呼び出す方がより正確でしょうか？
通常、レイヤーの名前は、アーキテクチャーのアプローチによって異なります。
- 従来のレイヤー は、プレゼンテーション/ビジネスロジック/データアクセスレイヤーです。
- 別の一般的なバリアントは Fowler’s プレゼンテーション/ドメインロジック/データソースレイヤーです。
- より最近のアーキテクチャは（データニュートラル） 六角形アーキテクチャ に触発され、より同心のイディオムを使用します。内部コアではエンティティとドメインロジックがあり、UIとデータベースアダプターは外部サークルに委任されています。
データアクセスレイヤーに選択した名前に関係なく、エンティティは原則として domainに属します。結局、それらはドメインオブジェクトとして定義されます。したがって、それらは基礎となるデータベースから独立している必要があります。
この原則に従う場合、DALまたは データソースレイヤー には、エンティティとデータベースを接続する接着剤のみが含まれます。これは、より近代的な建築モデルによって促進されたアプローチです。
それでも、アーキテクチャは白黒ではなく、最終的にはニーズに基づいて決定するのはあなた次第です。たとえば、一部のフレームワークと一部のアーキテクチャパターン（例： アクティブレコード ）は、データアクセスレイヤーのエンティティオブジェクトで機能します。これは、ドメインロジックがそれほど複雑ではないコンテキストや、主にデータコンテンツに焦点を当てたアプリケーションで頻繁に発生します。