領域驅動設計
限界上下文
劃分領域邊界，邊界內領域模型保持一致，
強調內聚，並與邊界外的領域模型解耦。
領域、子域
上下文映射圖
多個系統之間會發生關係，存在交互，這也必然會在各
自的Bounded Context上有所表現。上下文圖
（Context Map）便是表示各個系統之間關係的總體視圖
共享內核
將兩個團隊共享的子集剝離出來形成共享內核
雙方進行持續集成
客戶/供應商
不同系統之間存在依賴關係時，下游系統依賴上游系統，
下游系統是客戶，上游系統是供應商，雙方協定好需求，
由上游系統完成模型的構建和開發，並交付給下游系統使用，
之後進行聯調、測試。這種模式建立在團隊之間友好合作和支持的情況下
追隨者
如果上游系統不合作，這時候“客戶/供應商”模式就不湊效了，
那麼下游系統只能去追隨上游系統，
下游系統嚴格遵從上游系統的模型，簡化集成
防腐層
如果上游系統的模型不友好，
不適合下游系統的場景，但是下游系統又必須依賴於這些模型，
這時候我們需要使用防腐層（Anticorruption Layer）模式將上游系統的影響降低。
這種模式也是非常常見的，通常出現在系統間對接時，
使用trasport+resolver的方式完成服務調用和協議轉換。
其中的resovler便承擔了防腐的作用。
公開主機服務
能夠允許系統將一組service公開出去公其他系統訪問，
在互通模型的同時，減少了系統間的耦合
現在很火的微服務架構也可以理解爲此類模式的實現形式
各行其道
當兩個系統之間的關係並非必不可少時，
兩者完全可以彼此獨立，各自獨立建模，獨立發展，互不影響。
架構
實體
有唯一標識，可變的業務實體對象
它有着自己的生命週期。比如User、帖子等。
值對象
沒有唯一業務標識，通常依附於其他領域實體，值對象的內容不可變，
要麼被整體替換。如：用戶點贊行爲等。
領域服務
當某些業務行爲無法歸類到某一個Entity/Value Object時，
我們便可以創建領域服務來完成。
比如：賬戶轉賬場景，涉及到兩個不同的Account實體，
再比如社區的敏感詞過濾場景，帖子可以用，評論亦可以用，
因此可以抽離到ContentFilter中完成
領域事件
領域中發生的異步處理事件、異步消息通知等，
比如：異步寫入的登錄歷史記錄。
通常藉助消息隊列實現。
模塊
聚合
是一組業務關聯度很強的實體/值對象集合
每個聚合都有一個根實體（Root Entity）
通過根實體可以路由到整個聚合
工廠
用於複雜領域對象的創建/重建。
重建是指通過respostory加載持久化對象後，
重建領域對象。
資源庫
嚴格意義上將倉庫是基礎設施層的東西，
但是爲了保持領域模型的整體性，
我們將倉庫的接口定義放到領域中
，這樣可以在領域中約束實體/值對象的增刪改查接口，
同時還可以方便地完成倉庫的內存形式實現，
使得領域模型弱依賴於持久化層。