我有一个关于将DDD应用于开发丰富的GUI应用程序的哲学问题。作为一名程序员，我有创建DDD和面向数据库系统的经验，因此我了解基础知识。现在我正面临一个大型销售点应用程序的完全重新设计，我遇到了问题。
通常DDD概念意味着“99％的逻辑在域中，1％的逻辑在GUI中”; GUI中的逻辑只是一种验证。当你有简单的表格时，这种方法很有效，用户可以输入内容，然后按“保存”将数据发送到服务器或像这样发送。
现有应用程序的一个主要特点是它很快。使用POS意味着销售人员可以快速完成所有工作。 POS必须遵循的业务逻辑非常复杂。粗略地说，每当用户改变价格，税收，折扣等其他价格，支出，税收等变化时;所以这是一种驻留在客户端上的域名。
从技术上讲，我显然可以将逻辑移到服务器上的远程域，但它会使系统变得非常慢。每次用户在UI中进行更改时，我都需要进行远程调用。
有没有关于如何保持DDD纯度并同时使系统快速的想法？
谢谢！
P.S。我现在看到的唯一方法是使用包含域名的可下载程序集，但它看起来确实像黑客......
答案 0 :(得分：1)
需要谨慎管理，以便在UI响应和强制DDD纯度之间找到适当的平衡。
就个人而言，我喜欢采用默认的“纯粹”位置，只允许对DDD模式进行妥协，而现实世界的性能测试证明它是必要的。
我经常发现在服务器上保留多少逻辑而不会对客户端响应性产生负面影响是令人惊讶的，因为瓶颈并不一定是您期望的那样。
答案 1 :(得分：1)
一个概念是在客户端上进行一些快速验证，它不会尝试100％准确但可以检测到95％的无效输入。
在您的示例中，此快速验证可以检查以下内容：
仅当输入已通过快速客户端测试时，才会将输入发送到服务器以进行完全验证。
例如 - 假设我们有一个快速的客户端验证，准确率为95％。这意味着当用户输入无效数据时，在95％的情况下，UI将显示错误，无需服务器联系。
只有5％的无效输入数据会在服务器联系后首先显示错误。如果用户通常不提供无效数据，这可能就行了 - 这在一定程度上取决于用户界面的设计。
严重 - 快速验证绝不能说有效数据无效。
答案 2 :(得分：1)
可能你可以尝试使用分离的“两个应用程序”（两个模块），每个应用程序都像DDD哲学一样： - POS中的客户服务 - “服务器”中的商店服务...... 两个模块必须通过集成......例如通过网络...