?

• 領域：指一個具體的應用范圍，比如電商、訂票管理、會議管理等，實現某一領域的功能，與其對應的商業(yè)領域一致。譬如Contoso會議管理系統(tǒng)從兩個方面來闡述（1）系統(tǒng)概覽：銷售會議座位、創(chuàng)建新會議【領域的活動是什么，核心內容】（2）非功能性需求：擴展性、靈活性【降低維護成本，延長生命周期】。
• 有界上下文：引入本概念的目的是為大型、復雜系統(tǒng)的分解提供一種容易管理的方法。在這種分解方式下，一個大型系統(tǒng)由多個有界上下文構成，每個有界上下文所包含的是一個自包容的領域模型，且有自己本身的普適語言。可以將有界上下文看做是一個有著清晰一致性邊界的自動化的商業(yè)組件。在通常情況下，一個有界上下文更另一個有界上下文進行通信的方法是發(fā)送事件。
• 上下文線路圖：描述不同模型之間的接觸點，明確說明所有需要進行翻譯的通信鏈接，并注明任何共享模塊或對象。用戶在進行這些活動后得出的結果就是一種“上下文線路圖”。這種地圖提供的是整個系統(tǒng)的概覽，幫忙人民理解不同的有界上下文是如何相互交互的。
• 失血模型：模型僅僅包含數據的定義和getter/setter方法，業(yè)務邏輯和應用邏輯都放到服務層中。這種類在java中叫POJO，在.NET中叫POCO。
• 貧血模型：貧血模型中包含了一些業(yè)務邏輯，但不包含依賴持久層的業(yè)務邏輯。這部分依賴于持久層的業(yè)務邏輯將會放到服務層中。可以看出，貧血模型中的領域對象是不依賴于持久層的。
• 充血模型：充血模型中包含了所有的業(yè)務邏輯，包括依賴于持久層的業(yè)務邏輯。所以，使用充血模型的領域層是依賴于持久層，簡單表示就是 UI層->服務層->領域層<->持久層
• 脹血模型：脹血模型就是把和業(yè)務邏輯不想關的其他應用邏輯（如授權、事務等）都放到領域模型中。我感覺脹血模型反而是另外一種的失血模型，因為服務層消失了，領域層干了服務層的事，到頭來還是什么都沒變。
• 實體：
• 值對象：
• 聚合：
• 上下文：
• 函數式編程：
• 函數式編程三大思想：

immutable data 不可變數據：像Clojure一樣，默認上變量是不可變的，如果你要改變變量，你需要把變量copy出去修改。這樣一來，可以讓你的程序少很多Bug。因為，程序中的狀態(tài)不好維護，在并發(fā)的時候更不好維護。（你可以試想一下如果你的程序有個復雜的狀態(tài)，當以后別人改你代碼的時候，是很容易出bug的，在并行中這樣的問題就更多了）

first class functions：這個技術可以讓你的函數就像變量一樣來使用。也就是說，你的函數可以像變量一樣被創(chuàng)建，修改，并當成變量一樣傳遞，返回或是在函數中嵌套函數。這個有點像Javascript的Prototype。

尾遞歸優(yōu)化：我們知道遞歸的害處，那就是如果遞歸很深的話，stack受不了，并會導致性能大幅度下降。所以，我們使用尾遞歸優(yōu)化技術——每次遞歸時都會重用stack，這樣一來能夠提升性能，當然，這需要語言或編譯器的支持。Python就不支持。

• 函數式編程的技術：

map & reduce ：這個技術不用多說了，函數式編程最常見的技術就是對一個集合做Map和Reduce操作。這比起過程式的語言來說，在代碼上要更容易閱讀。（傳統(tǒng)過程式的語言需要使用for/while循環(huán)，然后在各種變量中把數據倒過來倒過去的）這個很像C++中的STL中的foreach，find_if，count_if之流的函數的玩法。
pipeline：這個技術的意思是，把函數實例成一個一個的action，然后，把一組action放到一個數組或是列表中，然后把數據傳給這個action list，數據就像一個pipeline一樣順序地被各個函數所操作，最終得到我們想要的結果。
recursing 遞歸 ：遞歸最大的好處就簡化代碼，他可以把一個復雜的問題用很簡單的代碼描述出來。注意：遞歸的精髓是描述問題，而這正是函數式編程的精髓。
currying：把一個函數的多個參數分解成多個函數， 然后把函數多層封裝起來，每層函數都返回一個函數去接收下一個參數這樣，可以簡化函數的多個參數。在C++中，這個很像STL中的bind_1st或是bind2nd。
higher order function 高階函數：所謂高階函數就是函數當參數，把傳入的函數做一個封裝，然后返回這個封裝函數。現象上就是函數傳進傳出，就像面向對象對象滿天飛一樣。

• Event Source： 事件源

基于事件源解決方案的核心要素是：

（1）在aggregate實例的狀態(tài)發(fā)生變化時，該實例將發(fā)起一個事件來完整描述此種狀態(tài)變化。

（2）系統(tǒng)將這些發(fā)生事件保存在一個事件庫里面。

（3）aggregate可以通過重播過去的事件流來重建自己的狀態(tài)。[在對系統(tǒng)的錯誤進行分析時，事件源和事件重播真是無價的。例如，我們可以首先在本地復制一個事件庫，然后在本地重播事件流來對應用程序進行調試，并理解到底在生產系統(tǒng)里面發(fā)生了什么事情。]

（4）其他aggregate和流程管理器（可能位于不同的有界上下文里）可以訂購這些事件。

• CQRS： Command Query Responsibility Segregation 命令查詢職責分離模式
• 自洽：自洽是操作的一種特性，意味著該操作能夠應用多次而不改變結果。例如，“將變量x的值設置為10”就是一個自洽操作，而“在x的值上面加1”則不是自洽操作。在消息傳遞環(huán)境中，如果一條消息可以傳遞多次而不會改變結果，則該消息是自洽的。消息自洽的原因有兩個：有可能是消息本身的性質使然，也有可能是系統(tǒng)處理消息的方法使然。【來自：探索CQRS和事件源.pdf 第137頁】

?

總結

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

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