この種のアプリケーションの正しいアーキテクチャを理解するのに苦労しています。これは、MSVisioに似たダイアグラム作成アプリケーションです。ダイアグラムは、別のアプリケーションに渡されるデータを生成するために使用されます。
アプリケーションを設計するとき、私は常にレイヤリングを使用しようとしましたが、データがプレゼンテーションと非常に緊密に結合されている場合、これを行う方法を決定できません。たとえば、私のキャンバス内の特定のオブジェクトには（X、Y）データがあります。これはプレゼンテーション目的でのみ使用されますが、ドメインデータのように保存する必要があります。
どこが間違っているのですか？私はこれを間違った角度から見ていると確信していますが、正しいものを理解することはできません。
再度、感謝します！
アップデート：
また、この場合、 UIをドメインから分離するべきではないことも認識しています。もしそうなら、いつ分離を適用するか、いつ適用しないかについての合理的な理由を教えてください。
ダイアグラム作成ツールでは、形状のx / y位置はドメインデータの一部であり（形状の位置は図の一部です-それなしでは図を描くことはできません）、それらのx/y座標を使用して描画するコード画面上の図形は、プレゼンテーション層の一部です。
表示にのみ使用されるデータは個別に保存する必要があると考える人もいますが、これまでに保存したデータを個別に作成したすべてのプロジェクトで、これは大きなメンテナンスとサポートの悪夢になりました。
単純なダイアグラム作成ツール（ツールがダイアグラムに基づいて特別な処理を行わずにダイアグラムを描画および編集するだけの場合）にはビジネスロジックはなく、ダイアグラム（プレゼンテーション層に属する）を描画および編集するコードのみがあります。ダイアグラムデータ（つまり、ドメインモデル）。
ビジネスロジックがない場合は、ドメインとプレゼンテーションに別々のオブジェクトセットを使用することで、すべてのモデルデータを2回（モデルオブジェクトで1回、プレゼンテーションオブジェクトで1回）複製する必要があり、利点は得られません。ビジネスロジックをプレゼンテーションから分離することから（何もないため）。
一方、データに対して実行するアルゴリズムがある場合は、グラフデータを描画コードから分離することで得られるものがあります。ツールの外部でアルゴリズムを実行したり、より優れた自動テストを実行したりできます。
また、同じデータで動作する別のシステムを作成する場合は、少なくともモデル定義を共有し、図面コードから分離すればコードを保存/ロードできます。
それで、要約しましょう：
すべてのダイアグラムデータはモデルの一部です（プレゼンテーション目的でのみ使用されるデータを含む）。
画面に描画したり、ユーザー入力を処理したりするものはすべて、（明らかに）プレゼンテーション層にあります。
これらの2つがすべてのコードとデータをカバーしている場合、アプリケーションには「ビジネスロジック」がなく、層の分離はおそらくやり過ぎです。
これらの2つのカテゴリに当てはまらないコードがあり、それが2つの別々の層を構築するよりも、モデルの一部である必要があると思われる場合。
システム間でコードを共有する可能性がある場合は、共有コードがプレゼンテーションコードと混ざっていないことを確認する必要があります。
そして最後の「ボーナス」ポイント-これが将来的に新しい機能が追加されて長期間活発に開発される可能性が高いプロジェクトである場合-とにかくUI/データを分離して将来の作業を容易にすることができます-あなたこの将来の節約が今余分な時間の価値があるかどうか、そしてこの分離が将来本当に役立つ可能性があるかどうかを決定する必要があります。
何をどのように分離しているかを確認する必要があると思います。表示しているのは、抽象、座標のセット、形状タイプです。それをどのように表示するかは非常に具体的です。ドメインモデルが純粋にwhatを処理し、ビューレイヤーがhowを一意に処理することを確認します。あなたのアプリについてもっと知らなければ、詳細に入るのは難しいです。
オブジェクトの現在のレイアウトを保存する、ある種のビューモデルの実装を試みることができます。このように、x / y値はオブジェクトのIDとともにレイアウトファイルに保存され、純粋なモデルデータは他の場所に保存されます。
多分これは少し役立ちます、