DDDでは、ファイルアクセスの境界コンテキストを定義する価値がありますか？
私はエディターを、ファイルからドキュメントとして開いたり、保存したり、保存したりするデスクトップアプリケーションとして設計しています。これは、実際には非常に一般的なことです。
私はすでにビジネスルールの境界コンテキストを持っています。
素朴に、エンティティを再水和するために使用されるファイルのパスをIDとして配置し、ファイルアクセスと管理を使用してリポジトリを実装したいと思います。
しかし、アプリケーションでファイルの側面を管理するのは適切な方法ではないと感じています。
それで、ファイル管理専用の境界コンテキストを設計することは興味深いかもしれないと思いますか？
DDDとファイル管理を組み合わせたそのようなアプリケーションの例はありますか？
ほとんどの例は、リポジトリを介したデータベースアクセスを示していますが、これまでのところ、それについては何も見つかりませんでした。
回答
私が理解しているように、ファイル管理はあなたのビジネスドメインの一部ではないので、専用の制限されたコンテキストは私の意見からは意味がありません。
プリミティブ文字列型として集計の識別子としてファイルパスを使用することに抵抗があることは、どういうわけか理解できます。したがって、この識別アスペクトをカプセル化し、ドメインモデルで動作するクライアントコードから抽象化するDocumentIdなどの値オブジェクトを作成することをお勧めします。リポジトリの実装の残りの部分は、コンテンツをデータベースに保存する場合と同じように機能します。ドメイン層でリポジトリインターフェースを使用し、リポジトリの実装はインフラストラクチャ層にあります。
この本から、私は、名前で表される概念に人々が同意できるように、十分に統合された開発領域としての有界コンテキストを理解しました。チーム間で分割が発生しているように見えます。チームは、コミュニケーションや調整をあまり行わずに、問題の別々の側面に取り組んでいます。（この質問でもこれについて説明しています）
あなたが説明する問題は、複数のチームにわたって処理する必要があるようには思えません。汎用サブドメインのように、ファイル管理を別のモジュールに移動するだけで済みます。