7
私は最初の「本当の」DDDアプリケーションに取り組んでいます。DDD。ユーザーの設定可能な設定はどこに属していますか？
現在のところ、クライアントは自分のドメイン層にアクセスできず、コマンドを発行してドメインへの変更を要求します。
次に、単純なCQRSのような情報を表示するための別の（平坦化された）読み取りモデルがあります。
私は現在、ユーザーが設定する設定、具体的には設定について作業中です。例としてブログアプリケーションを使用すると、設定はブログタイトルまたはロゴである可能性があります。
シンプルなキー値ペアのコレクションに基づいて厳密に型指定された設定オブジェクト（BlogSettingsなど）を構築する一般的な設定ビルダーを開発しました。これらの設定オブジェクトが私のドメインの一部であるかどうかはわかりません。クライアントとサーバーからアクセスする必要があります。
これらの設定オブジェクトを含む「共有」ライブラリを作成することを検討しています。これは正しいアプローチですか？
最後に、このような構成設定を保存するコードはどこにあるべきですか？簡単な解決策は、このコードを私のDomain.Persistenceプロジェクトに置くことですが、ドメインの一部でない場合は、本当にそこにいるべきですか？彼らは強く型付けされたとユビキタス言語、すなわち「blog設定」に基づいてモデル化されている場合
おかげで、
ベン
別の「設定」または「設定」境界のあるコンテキストがあるかもしれません。論理的な分離であり、物理的な分離ではありません。したがって、さまざまな技術（クライアントとサーバー）を使用してコンテキストへのアクセスを提供することができます。しかし、これを行うためのすべてのコードはコンテキストに属します。 –
@ YvesReynhoutこれは私たちがやりとりしたルートで、私たちがやり取りする設定コンテキストを持っています。ただし、構成オブジェクトを共有しました。この場合、分離によって不要なコードの重複が発生しただけです。 –
ああ、しかし、論理的な分離は、コードの重複につながることはありません。これは、境界のあるコンテキストがコードを担当していることを意味します。バインドされたコンテキストのコードがどのようにデプロイされるのかは、その事実と完全に直交しています（他のバインドされたコンテキストのコードとともにプロセス内で完全にホストされる可能性があります）。 –