2019獨角獸企業重金招聘Python工程師標準>>>

本文既不推銷UML，也不推廣DDD，更不涉及各種論戰。-- 作者

? ? 某天又一次打開關于DDD(領域驅動設計)的PDF文檔時，自己有了個疑問：什么是領域(Domain)？譯文中是這樣描述領域：銀行業務被銀行的內部人員和專家所熟知。他們知道所有的細節、所有的困難、所有可能?出現的問題、所有的業務規則。這些就是我們永遠的起始點：領域。如果這就是領域，它似乎不是"起始點"，而是“全部”--全部的業務規則、全部的細節、全部可能出現的問題。我的疑問正是始于此：Domain映射到軟件，"全部"不就是整個系統？

? ? 這里有個概念漏洞，Domain是"全部"，但不是全世界的"全部"，那它是什么的全部？顯然，譯文中看到的"銀行業務"，其對應的Domain也不是指銀行業務系統的全部，因此Domain的概念相對清晰--一個有清晰邊界、內部的業務、規則、問題、細節都自成一派--你會問我，這是指對象(Object)吧！如果從低層次上講，兩者是有關系的。下一個疑問：Domain和Object有什么不同？

? ? 我思考的結果是封裝的級別不同：Object封裝的目標是調用其方法實現所承諾的功能，但系統中的對象是有依賴的；Domain封裝的目標是"全部"都在這里，即不需要依賴其他的Object或者Domain。之所以這么想，主要的依據是從那個常用的例子：機場、航線、飛機，雖然我看的譯文中把這三個定義為對象，使用UML畫了聚合關系；我更傾向于把它們看成Domain，即我認為機場不會調用飛機的方法（或者人），兩者只是相互關注了對方(的事件)。例如，飛機A1和機場B1通過無線電溝通(消息)。Object間的消息一般是帶著發送者或者接受者的數據，也就是A1發送的是B1要處理的；而Domain間的消息是否處理，如何處理則是完全由接收者自己處理，發送者也不關心消息的處理。再一個疑問：如何達到"全部"封裝？

? ? 上面的例子中，我使用了"事件"這個關鍵字。事件(消息)不是新鮮事物，在面向對象的系統中，其作為異構子系統、系統間異步調用的橋梁，起著重要的作用；所以我認為“事件通知”不是實現Domain的途徑，因為它是同步調用的變種：消息的生產者和消費者仍然有業務邏輯上的天然聯系。事件除了通知，還有一種模式是監聽。這種事件是公共資源，是開放的標準，不論采用廣播、總線、管道各種模式，Domain監聽自己關注的事件，并對其進行響應，如果產生了新的（"開放"）事件，則將事件發布回(廣播、總線、管道的)'通道'。以機場和飛機為例，機場廣播的跑道天氣信息，飛機的飛行員如果關心，則通過無線電接聽，如果不關心，則完全可以關閉無線電。

? ? 以上基本展示了我思考的過程。其間，我回顧了自己使用過的各種(X)O，(X)O包含面向服務(架構)-SO(A)，面向方面(編程)-AO(P)，面向對象-OO，面向過程-PO。

粗略地得到了下圖：

從上圖中除了有關于Domain的思考，還想了關于如何更好的使用各種方法論。我有個觀點：同步就是兩次或者多次異步交互的集成。

? ? 畫圖的過程中，我又有了個疑問：服務間的異步通知類接口，是否是實現Domain的一種形態？通過與分布式服務系統的拆分，我認為：異步通知(接口)是一種補充，而不是Domain間交互的主要方式，它類似“塔臺呼叫711，711聽到請回答”；如果全程都是這樣飛行，塔臺需要為每個飛機配置一個導航員，且每個飛機獨立使用一個頻率，這不是一個好設計，盡管它在航空管制初期可能是可行的。

? ? 我的結論是：面向領域設計DDD中的領域是比對象、服務更加高度的封裝，領域包含自己的數據、行為、控制等"全部"，并對外部事件（或者消息）做出響應，按照自己的規則完成特定的功能。基于這樣的特點，Domain間的通訊應該是異步事件監聽模式。在Domain內部，可以利用面向對象、服務及各種方法論開發更耦合的功能--這可以解釋為什么現在更多的系統是采用的同步調用方式運行。這也是另一個層面的“外松內緊”的耦合。

轉載于:https://my.oschina.net/u/1053238/blog/359106

總結

以上是生活随笔為你收集整理的关于DDD中Domain的思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。