前言：
企業應用程式的核心是業務邏輯，業務邏輯實現了業務規則。但是由於業務邏輯分散在多個服務上，因此在微服務架構中開發複雜的業務邏輯更具有挑戰性。
我們需要解決兩個問題：
首先，典型的領域模型是由各種類交織在一起的乙個網路。雖然這在單體應用程式中不是問題，但是在微服務架構中，類分散在不同的服務中，就需要跨越服務邊界（也就是程序）的物件應用
其次，是在設計微服務架構下的業務邏輯，這些業務邏輯受到微服務下事務管理的種種約束。我們的業務邏輯可以在乙個服務內部使用acid事務，它必須使用saga模式來維護服務之間的資料一致性
好在，我們可以使用領域驅動設計中的聚合模式來解決這些問題。聚合模式下，服務的業務邏輯通過多個聚合組成的乙個集合來體現。聚合是一組物件，可以作為乙個單元來處理。在微服務架構中開發業務邏輯時，聚合可以起到以下兩個重要的作用：
使用聚合可以避免任何跨服務邊界的物件引用，因為聚合之間通過主鍵進行引用，而不是通過物件的位址進行引用
由於單個事務只能建立或更新單個聚合，因此聚合滿足微服務事務模型的約束
業務邏輯組織模式
例如 go-micro微服務框架流程：
- proto/.micro.go：檔案是入站介面卡，接收來自客戶端的rpc請求，找到請求物件的方法，呼叫業務邏輯（handler）
- handler：就是業務邏輯目錄，在handler中放置業務邏輯類，業務邏輯根據入站介面卡傳入的出站介面卡結構體引數，根據出站介面卡，返回資料，呼叫出站介面卡，完成業務邏輯的處理
- proto/.pd.go：檔案是出站介面卡，定義了返回給客戶端的引數，以及出站的業務邏輯。
- 業務邏輯通常是服務中最複雜的部分。在開發業務邏輯時必須做出的關鍵決策是選用物件導向，還是面向過程。組織業務邏輯有兩種模式：面向過程的事務指令碼模式和物件導向的領域建模模式。
- models：即是我們自己定義擴充套件的databases 資料模型
使用領域模型模式設計業務邏輯
關於領域驅動設計
領域驅動設計（ddd）是對物件導向設計的改進，是開發複雜業務邏輯的一種方法。領域驅動設計的子域概念有助於把應用程式分解為服務。使用ddd時，每個服務都有自己的領域模型，這就避免了在單個應用程式全域性範圍內的領域模型問題。子域和相關聯的界限上下文的相關概念是兩種戰略性ddd模式
開發人員廣泛採用的基本元素包括以下幾種：
實體：具有持久化id的物件。具有相同屬性值的兩個實體仍然是不同的物件
值物件：作為值集合的物件。具有相同屬性值的兩個值物件可以互換使用。值物件的乙個例子是money類，它由幣種和金額組成
工廠：負責實現物件建立邏輯的物件或方法該邏輯過於複雜，無法由類的建構函式直接完成。它還可以隱藏被例項化的具體類。工廠方法一般可實現為類的靜態方法
服務：實現不屬於實體或值物件的業務邏輯的物件
使用聚合模式設計領域模型
總結：事務指令碼模式通常是實現簡單業務邏輯的好方法。但是在實現複雜的業務邏輯時，應該考慮使用物件導向的領域模型模式
設計服務的業務邏輯的好方法是使用ddd聚合。ddd聚合很有用，因為它們把領域模型模組化，消除了服務之間物件的直接引用，並確保每個acid事務都在服務內
建立或更新聚合時應發布領域事件。領域事件具有廣泛的用途。領域事件的訂閱者還可以通知使用者和其他應用程式，並將websocket訊息發布到使用者的瀏覽器。
業務邏輯設計
1.action設計 shfwpgdzlbdmanager.copy mannager裡面的相應方法 shfwpgdzlbd.getbdtpid 傳入的引數從哪獲取，型別應和mannager的方法需要的引數型別相同 2.manager設計 設計之前宣告物件 private shfwpgdzlbdda...
業務設計 邏輯設計及物理設計
針對資料庫的邏輯設計主要是指正規化設計和反正規化設計，首先來看一下我們的正規化設計 1.第一正規化 比如在使用者表user中，我們可以有姓名 性別 年齡 這些都是單獨的列，不能夠把性別和年齡組合一起當成乙個列。如下 姓名性別 年齡 張三 男 18 2.第二正規化 比如我們訂單表中，我們一張訂單中可能...
邏輯設計中多時鐘設計 2
在上個系列中，主要分析了單bit時鐘訊號是如何在多個時鐘域中進行同步的。概括起來只有兩點 一是通過同步器，二是將控制訊號與資料訊號合併成一組 資料 控制 匯流排，經過fifo或ram實現跨時鐘域設計。那麼在這節中，重點來分析跨時鐘域這個概念。通過這節的分析，可以知道那些型別的時鐘，在實際的處理過程中...