DDD及相關概念 - zsy－IT工程師數位筆記本

文章出處

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

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

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

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

函數式編程的技術：

map & reduce ：這個技術不用多說了，函數式編程最常見的技術就是對一個集合做Map和Reduce操作。這比起過程式的語言來說，在代碼上要更容易閱讀。（傳統過程式的語言需要使用for/while循環，然后在各種變量中把數據倒過來倒過去的）這個很像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實例的狀態發生變化時，該實例將發起一個事件來完整描述此種狀態變化。

（2）系統將這些發生事件保存在一個事件庫里面。

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

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

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