從0開發3D引擎（補充）：介紹領域驅動設計

　　VO（View Object）：視圖對象，用於展現層，它的做用是把某個指定頁面（或組件）的全部數據封裝起來。
　　DTO（Data Transfer Object）：數據傳輸對象，這個概念來源於J2EE的設計模式，原來的目的是爲了EJB的分佈式應用提供粗粒度的數據實體，以減小分佈式調用的次數，從而提升分佈式調用的性能和下降網絡負載，但在這裏，我泛指用於展現層與服務層之間的數據傳輸對象。
　　DO（Domain Object）：領域對象，就是從現實世界中抽象出來的有形或無形的業務實體。
　　PO（Persistent Object）：持久化對象，它跟持久層（一般是關係型數據庫）的數據結構造成一一對應的映射關係，若是持久層是關係型數據庫，那麼，數據表中的每一個字段（或若干個）就對應PO的一個（或若干個）屬性。

通用語言，又叫統一語言

事件風暴

咱們使用事件風暴做爲DDD的開始，獲得通用語言。

相關資料爲：
領域驅動設計: 服務邊界劃分
 使用事件風暴探索業務全景

領域和子域

相關資料爲：
DDD理論學習系列（2）-- 領域

限界上下文

相關資料爲：
DDD理論學習系列（3）-- 限界上下文

上下文映射圖

參考DDD—上下文映射圖，上下文之間有下面的關係：

合做關係（PS）：若是兩個限界上下文的團隊要麼一塊兒成功，要麼一塊兒失敗，此時他們須要創建起一種合做關係。他們須要協調開發計劃和集成管理。
共享內核（SK）：對模型和代碼的共享將產生一種緊密的依賴性，對於設計來講，這種依賴性可好可壞。咱們須要爲共享的部分模型指定一個顯式的邊界，並保持共享內核的小型化。共享內核具備特殊的狀態，在沒有與另外一個團隊協商的狀況下，這種狀態是不能改變的。咱們應該引入一種持續集成過程來保證共享內核與通用語言的一致性。
客戶方——供應方開發（CSD）：當兩個團隊處於一種上游-下游關係時，上游團隊可能獨立於下游團隊完成開發，此時下游團隊開發可能會受到影響。所以，在上游團隊的計劃中，咱們應該顧及到下游團隊的需求。
遵奉者（C）：在存在上游-下游關係時，若是上游團隊已經沒有動力提供下游團隊之所需，下游團隊便孤軍無助了。只能盲目地使用上游團隊的模型。
防腐層（ACL）：在集成兩個良好的限界上下文時，翻譯層可能很簡單，甚至能夠很優雅地實現。可是，當共享內核、合做關係或客戶方-供應方關係沒法順利實現時，此時的翻譯將變得複雜。對於下游客戶來講，你須要根據本身的領域模型建立一個單獨的層，該層做爲上游系統的委派向你的系統提供功能。防腐層經過已有的接口與其餘系統交互，而其餘系統只須要作很小的修改，甚至無須修改。在防腐層內部，它在你本身的模型和他方模型之間進行翻譯轉化。
開放主機服務（OHS）：定義一種協議，讓你的子系統經過該協議來訪問你的服務。你須要將該協議公開，這樣任何與你集成的人均可以使用該協議。在有新的集成需求時，你應該對協議進行改進或者擴展。對於一些特殊的需求，你能夠採用一次性的翻譯予以處理，這樣能夠保持協議的簡單性和連貫性。
發佈語言（PL）：在兩個限界上下文之間翻譯模型須要一種公用的語言。此時你應該使用一種發佈出來的共享語言來完成集成交流。發佈語言一般與開放主機一塊兒使用。
另謀他路（S）：在肯定需求時，咱們應該作到堅持到底。若是兩套功能沒有顯著的關係，那麼它們也能夠被徹底解耦的。聲明兩個限界上下文之間不存在任何關係，這樣使得開發者去尋找簡單的、專門的方法來解決問題。

相關資料爲：
看看上下文映射的清晰視圖
 DDD—上下文映射圖