在客戶端和服務器之間共享模型

Question

由於我們的域模型和過程，我們正在研究客戶端和服務器之間的共享模型。我們的客戶是非常厚實的客戶。 有沒有關於這種架構的任何信息，優點和缺點？

Answer 1

理論上如果你的域層完全去耦（來自持久性，表示，基礎設施等），它可以很容易地在不同的地方作爲一個庫重用。

然而，正如阿德里安指出，這引發了實際問題：

• 安全性：在客戶端應用程序分發特別是您的域名是有風險的。解決方法之一是如果客戶端是桌面應用程序，則會混淆二進制文件。

• 平臺不匹配：您可能無法在客戶端和服務器上使用相同的技術/語言。這將導致您的域的翻譯，基本上翻倍的工作量，維護成本和錯誤傾向性。

• 版本控制：即使重複使用相同的庫，客戶端和服務器上的版本也必須保持同步以防止出現不兼容問題。

此外，除非您開發的Web版本是桌面版本的精確克隆，否則我認爲域的重複使用最多隻能是部分。在單個客戶端/服務器應用程序的情況下，我很想知道爲什麼要在兩個層上使用相同的域......通常，客戶端上的數據結構可能看起來有點像域實體，但調整爲用戶界面，並沒有任何行爲。在這種情況下，重新使用客戶端的整個域圖層將意味着拖拽一個龐大的對象圖表，這可能會部分滿足您的需求，但也包含大量其他不需要的內容。

也許你需要的是來自域驅動設計的Bounded Context的概念 - 相同的類名，但在客戶端上下文和服務器上下文中略有不同的類。

Answer 2

DDD和現代開發實踐鼓勵將域邏輯保留在客戶端之外。現在，客戶端發生的大部分代碼都是爲了充分利用客戶端平臺的GUI優勢。

將域邏輯保留在客戶端之外的兩個很好的理由是安全性和可維護性。

爲了安全起見，服務器應規定客戶端可以執行的操作。客戶端可以被黑客入侵，但是如果所有的域邏輯和安全都在服務器中，那麼黑客（客戶端）上的黑客就不會繞過或破壞系統。

爲了可維護性，如果所有的域邏輯都在服務器上，那麼它就在一個地方。如果它在一個地方（或者更好的是在一個明確定義的模塊或命名空間中），那麼團隊中的任何人都可以更容易地維護代碼。