我无法为这种应用程序找出正确的架构：它是一个图表应用程序，类似于 MS Visio。这些图表用于生成传递给另一个应用程序的数据。
在设计应用程序时，我一直尝试使用分层，但现在我无法决定在数据与表示形式如此紧密耦合的情况下如何做到这一点。例如，我画布中的某个对象有一个 (X,Y) 数据，该数据仅用于演示目的，但必须像域数据一样存储。
我哪里弄错了？我很确定我是从错误的角度看待这个问题，但我无法找出正确的角度。
再次感谢！
更新：
我也知道，在这种情况下，也许我不应该将 UI 与域分开。如果是这样，请向我提供一些关于何时应用分离以及何时不应用的理性。
在绘图工具中，形状的 x/y 位置是域数据的一部分（形状的位置是图表的一部分 - 没有它就无法绘制图表），使用这些 x/y 坐标并绘制的代码屏幕上的形状是表示层的一部分。
我知道有些人认为仅用于显示的数据应该单独保存，但在我曾经处理过的每个项目中，单独保存的数据变成了巨大的维护和支持噩梦。
在一个简单的图表工具中（如果工具只是绘制和编辑图表而没有基于图表进行任何花哨的处理）没有业务逻辑，只有绘制和编辑图表的代码（属于表示层）和图数据（即领域模型）。
如果没有业务逻辑，通过对域和表示使用单独的一组对象，您将不得不复制所有模型数据两次（一次在模型对象中，一次在表示对象中）并且您不会获得任何优势将业务逻辑与表示分离（因为没有）。
另一方面，如果您确实有一些算法可以在数据上运行，那么您可以通过将图形数据与绘图代码分离来获得一些收益——您可以在工具之外运行算法，您可以进行更好的自动化测试等。
此外，如果您编写另一个对相同数据进行操作的系统，如果您将其与绘图代码分开，您至少可以共享模型定义和保存/加载代码。
所以，让我们总结一下：
所有图表数据都是模型的一部分（包括仅用于演示目的的数据）。
任何绘制到屏幕或处理用户输入的东西都在表示层中（显然）。
如果这两个覆盖了您的所有代码和数据，那么您的应用程序就没有任何“业务逻辑”，并且层分离可能是多余的。
如果您有任何代码不属于这两个类别，并且您认为它应该是模型的一部分，那么您应该构建两个单独的层。
如果系统之间有任何代码共享的机会，您应该确保共享代码没有与演示代码混合。
最后一个“奖励”点——如果这是一个很可能在很长一段时间内积极开发并在未来添加新功能的项目——你可能想要分离 UI/数据只是为了让未来的工作更容易——你必须决定这种未来的节省是否值得现在额外的时间，以及这种分离是否真的有可能在未来有所帮助。
我认为您需要确保将内容和方式分开。您显示的是抽象的、坐标集、形状类型。你如何显示它是非常具体的。我会确保域模型纯粹处理什么，而视图层唯一处理方式。尽管不了解您的应用程序的更多信息，但很难进入细节。
您可以尝试实现某种视图模型，以保存对象的当前布局。这样，x/y 值与对象的 id 一起存储在布局文件中，而纯模型数据存储在其他地方。
也许这有点帮助，