由于我们的领域模型和流程，我们正在寻找客户端和服务器之间的共享模型。我们的客户确实是厚客户。 有没有关于这种架构及其优缺点的信息？
理论上如果你的领域层完全解耦（与持久性、表示、基础设施等），它可以很容易地在不同的地方作为库重用。
然而，正如阿德里安指出的，这提出了实际问题：
安全性：分发域（尤其是在客户端应用程序中）可能存在风险。解决这个问题的一种方法是，如果客户端是桌面应用程序，则混淆您的二进制文件。
平台不匹配：您可能无法在客户端和服务器上使用相同的技术/语言。这将导致您的域名的翻译，基本上使初始工作量、维护成本和错误倾向增加一倍。
版本控制：即使重复使用同一个库，客户端和服务器上的版本也必须保持同步，以防止不兼容。
此外，除非您正在开发一个与桌面版本完全相同的网络版本，否则我认为域重用最多只能是部分的。在单个客户端/服务器应用程序的情况下，我很想知道为什么您会在两层上使用相同的域...通常您在客户端拥有的数据结构可能看起来有点像域实体，但针对 UI 进行了调整，并且没有任何行为。在这种情况下，在客户端重用整个域层将意味着拖动一个庞大的对象图，该对象图可能部分满足您的需要，但也完成大量其他不需要的东西。
也许您需要的是领域驱动设计中的有界上下文的概念 - 相同的类名，但客户端上下文和服务器上下文中的类略有不同。
DDD 和现代开发实践鼓励将领域逻辑排除在客户端之外。 如今，大多数发生在客户端的代码都是为了利用客户端平台的 GUI 优点。
将域逻辑保留在客户端之外的两个充分理由是安全性和可维护性。
为了安全起见，服务器应该规范客户端可以做什么。 客户端可能会被黑客攻击成碎片，但如果所有域逻辑和安全性都在服务器中，那么（在客户端上）再多的黑客攻击也无法规避或损坏系统。
为了可维护性，如果所有域逻辑都在服务器上，那么它就在一个地方。 如果它位于一个地方（或者更好地位于明确定义的模块或命名空间中），那么团队中的任何人都可以更轻松地维护代码。