軟體在本質上是複雜的，軟體本身的複雜性在于除了要解決問題域，還要解決非功能性需求和軟體域特有問題：安全性、可用性、可維護性、可擴充性、性能、一緻性、容錯性、穩定性、可重用性、幂等、相容等等，軟體開發者的任務就是制造“簡單”的假象。如何組織複雜的系統？把複雜的事物分解到不同的層次中，層次代表了不同級别的抽象，一層建構于另一層之上，每一層都對上層屏蔽内部複雜度。
一 為什麼使用RDD？
在RDD中，我們認為“軟體對象具有職責”，這個定義很符合人在社會群體中分工協作的方式，軟體也是人編寫的，是以根據職責思考設計的軟體系統符合人的行為習慣，同時更易于了解和管理。在微服務架構中不同系統由不同的組織和人負責，把系統當作對象（人），系統提供的接口就是對象（人）的職責。
職責驅動設計的核心是考慮怎樣給對象配置設定職責，其适用于大到系統、小到對象等任何規模的軟體。職責配置設定的本質是分工，勞動分工是勞動生産率提高的主要原因。
- 熟練度的提高，專注于某個領域（降低複雜度）。
- 時間的節約，同一個人在不同工作來回切換需要耗費大量時間。
- 人工發明的機器和應用（特定領域的工具）。
二 如何給對象(元素)配置設定職責？
配置設定職責應當從清晰的描述職責開始，對于軟體領域對象來說，領域模型描述了領域對象的屬性和關聯，對應類的屬性和引用，用例模型包含一系列的行為活動，對應類的方法。領域模型建立方式可參考《UML和模式應用》、UDD、DDD。
使用GRASP（General Responsibility Assignment Software Patterns）模式配置設定職責，GRASP是通用職責配置設定模式，是對一些基本的職責配置設定原則進行了命名和描述，共9種模式（一些GRASP原則是對其他原則和設計模式的歸納，設計模式有上百種，隻是記住GoF 23種設計模式就已經很困難了，更别提還要記住每種模式的細節，是以需要對設計模式進行有效的歸類。GRASP中的原則描述了模式的本質，除了有助加速設計模式學習之外，對發現現有設計存在的問題也更有效，這就是歸納的價值）。
當談論低耦合、高内聚時，我們具體是在談什麼？問題不在于耦合度高、内聚性低，而是在于其産生的負面影響，負面影響往往是在發生變化時展現出來的，這些負面影響會影響到我們開發的效率、穩定性、可維護性、可擴充性、可複用性等等，整個GRASP的核心是如何防止變異（變化）。
在學習過程中發現GRASP缺少結構化的展示歸納結果，通過我自己的了解把開發中常用的GoF設計模式、面向對象設計原則、架構設計原則和GRASP進行關聯：
三 GRASP職責配置設定模式
1 防止變異
該模式基本等同于資訊隐藏和開閉原則。如何做到在不修改原來功能的前提下對變化的部分進行擴充？識别不穩定因素是特别困難的，也決定了我們能否做出符合開閉原則的設計。
問題：如何設計對象、子系統和系統，使其内部的變化或不穩定性不會對其他元素産生不良影響。
解決方案：識别預計變化或不穩定之處，配置設定職責用以在這些變化之外建立穩定接口。
相關原則和模式：
- GRASP：間接性、多态
- GoF：大量模式
- 其他：接口、資料封裝
2 低耦合、高内聚
耦合是對某元素與其他元素之間的連接配接、感覺和依賴程度的度量，内聚是對元素職責的相關性和集中度的度量（這裡的元素指類、系統、子系統等等），耦合和内聚是從不同角度看待問題，他們互相依賴的互相影響的（以下兩點也可以反過來說）：
- 内聚過低，相關功能分散在不同子產品中，需要增加額外的耦合使這些功能聚合在一起，發生變更時影響多個子產品。
- 内聚過高，不相關的功能聚集在一個子產品中，耦合度高，發生變更時會産生意想不到的影響。
低耦合
耦合是對某元素與其他元素之間的連接配接、感覺和依賴程度的度量。這裡的元素指類、系統、子系統等等。
問題：怎樣降低依賴性，減少變化帶來的影響，提高重用性？
解決方案：配置設定職責，使耦合盡可能低。利用這一原則評估可選方案。
相關模式或原則：
- GRASP：防止變異
注意：耦合不能脫離專家、高内聚等其他原則獨立考慮。
緊密耦合的系統在開發階段有以下的缺點：
- 一個子產品的修改會産生漣漪效應，其他子產品也需随之修改（通常是内聚低引起的）。
- 由于子產品之間的相依性，子產品的組合會需要更多的精力及時間，可複用性低（通常是耦合高引起的）。
解讀：耦合表示元素之間存在依賴，當談論“耦合高”時，我們具體是在談論什麼呢？是依賴産生的負面影響，是以低耦合的核心是解決不良依賴。高低是度量并不是評判耦合結果好壞的标準，使用“不良耦合”、“松耦合”描述的更為準确。不良耦合産生的負面影響主要有兩點：
- 依賴關系本身錯綜複雜難以維護和了解，很容易産生遺漏和問題（這點針對人，人處理複雜性事物時能力是局限的）。
- 與不穩定元素産生依賴時很容易受到變化的影響（通常無法避免不依賴）。
那麼如何做呢？先對依賴關系的好壞進行評估：依賴方式、依賴方向、依賴鍊路。
方向：
- 雙向依賴（差）
-
- 互相依賴的兩個元素不能獨立行動，在微服務系統架構的系統中類級别不會産生特别複雜的問題，但是在子產品 or 系統級别就特别容易受到變化帶來的影響。
-
- 舉例：A <-> B，A調用B的b接口，B的b接口依賴A的a接口，如果a b接口都要變更，兩個系統如何釋出？A依賴B先釋出，B也依賴A先釋出，互相依賴的兩個元素不能獨立行動。
- 循環依賴（更差）
-
- 循環依賴比雙向依賴的的鍊路更長，影響的範圍更大。
- 單向依賴（好）
鍊路：
- 深度
-
- B調用A.getC().getD().getE().getF() 擷取到F。
- 廣度
-
- 在鍊路變寬的過程中不加以限制和管理很容易産生大雜燴的元素，也很容易産生雙向和循環依賴。
方式：
- 内容耦合（高）
-
- 當一個子產品直接使用另一個子產品的内部資料，或通過非正常入口而轉入另一個子產品内部。
- 共享耦合/公共耦合（高）
-
- 指通過一個公共資料環境互相作用的那些子產品間的耦合。
-
- 公共耦合的複雜程度随耦合子產品的個數增加而增加。
- 控制耦合（中）
-
- 指一個子產品調用另一個子產品時，傳遞的是控制變量（如開關、标志等），被調子產品通過該控制變量的值有選擇地執行塊内某一功能;
- 特征耦合/标記耦合（中）
-
- 指幾個子產品共享一個複雜的資料結構，如進階語言中的數組名、記錄名、檔案名等這些名字即标記，其實傳遞的是這個資料結構的位址;
- 資料耦合（低）
-
- 指子產品借由傳入值共享資料，每一個資料都是最基本的資料，而且隻分享這些資料（例如傳遞一個整數給計算平方根的函數）。
- 非直接耦合（低）
-
- 兩個子產品之間沒有直接關系，它們之間的聯系完全是通過主子產品的控制和調用來實作的。耦合度最弱，子產品獨立性最強。
- 無耦合（無）
-
- 子產品完全不和其他子產品交換資訊。
解決不良依賴：
- 管理複雜的依賴關系
-
- 依賴方向：使用單向依賴，去除或弱化雙向依賴，不使用循環依賴。
-
- 依賴鍊路：遵守最少認知原則。
-
- 依賴方式：盡量使用資料耦合，少用控制和特征耦合，控制公共耦合的範圍，不使用内容耦合，如果依賴的對象不穩定使用非直接耦合來弱化耦合緊密程度。
- 配置設定正确的職責減少不必要的依賴：專家、建立者。
- 通過其他原則和模式減少不穩定元素帶來的影響：高内聚、純虛構、控制器、多态、間接性、最少認知。
高内聚
内聚是對元素職責的相關性和集中度的度量。
問題：怎麼樣保持對象是有重點的、可了解的、可維護的，并且能夠支援低耦合？
解決方案：按照相關性配置設定職責，可保持較高的内聚。
優點：
- 分解後的元素更加簡單易于了解和維護。
- 按照相關性拆分可以提高重用性。
相關原則和模式：單一職責原則、關注點分離、子產品化。
低内聚的缺點：内聚性較低的類要做許多不相關的工作，或需要完成大量的工作，這樣的類會導緻以下問題：
- 難以了解
- 難以複用
- 難以維護
- 經常會受到變化影響
例子：A的變更影響從3個子產品變為1個。
小結
通過結構化管理來保持低耦合、高内聚。
3 建立者
建立者指導我們配置設定那些與建立對象有關的職責。如此選擇是為了保持低耦合。
問題：誰應該負責建立某類的新執行個體？
解決方案：滿足以下條件之一時，将建立類A的職責配置設定給類B（當滿足1條以上時，通常首選包含或聚合）。
- B“包含”或聚合A。
- B記錄A。
- B頻繁使用A。
- B具有A的初始化資料，該資料将在建立時傳遞給A。
優點：支援低耦合，因為建立者和被建立者已經存在關聯，是以這種方式不會增加耦合性。
- GRASP：低耦合
- GoF：具體工廠、抽象工廠
- 其他：整體-部分
注：包含（作者在這裡标注了“”，因為包含在uml是表達用例關系的，用來說明對象關系也可以）、聚合、整體-部分 看UML定義；包含強調了強依賴（A是B的子集，A屬于B，缺少了A時B不是整體），聚合是弱依賴（B由A組成，A不屬于B）。
例子：
- Order包含Goods（Order脫離Goods就失去了完整性，沒有存在的意義）。
- Order記錄相關的Goods。
- Goods初始化資料：
-
- 情況一：隻需要訂單上的Goods資料，這種情況Order具有Goods的初始化資料。
-
- 情況二：訂單上的Goods資料不完整，這種情況Order隻有Goods初始化資料的一小部分，Order不能做為建立者。
4 資訊專家(or 專家)
“資訊”不單指資料。
問題：給對象配置設定職責的基本原則是什麼？
解決方案：把職責配置設定給資訊專家，它具有實作這個職責所必需的資訊
- 對象使用自身資訊來完成任務，是以資訊的封裝性得以維持，是以支援了低耦合（至少不會增加耦合性）。
- 行為分布在那些具有所需資訊的類之間，這樣功能更集中，是以支援了高内聚。
- GRASP：低耦合、高内聚
注意：和“關注點分離”一起使用使得對象進一步内聚，進而達到高内聚，也能降低耦合。
舉例：擷取所有買的商品總金額，Order和Goods是一對多的關系。
分析：Order本身關聯了Goods，并且了解Goods的結構。在圖例中Client通過Order擷取了Goods并做了邏輯運算得出商品總金額，這種做法産生了不必要的依賴增加了耦合數量，商品總金額計算的職責由Order承擔最合适。
延伸：在某些情況下，該方案并不合适，通常是由于耦合與内聚問題産生的，如：誰應該把對象A存入資料庫？按照原則每個類都應該具有把自己持久化的能力。
5 純虛構
為了保持良好的耦合和内聚，捏造業務上不存在的對象來承擔職責。
問題：當你并不想違背高内聚和低耦合或者其他目标，但是基于專家模式所提供的方案又不合适時，哪些對象應該承擔這一職責？
解決方案：對人為制造的類配置設定一組高内聚的職責，該類并不代表問題領域的概念--虛構的事物，用以支援高内聚、低耦合和複用。
- 支援高内聚，因為職責被解析為細粒度的類，這種類隻着重于極為特定的一組相關任務。
- 增加了潛在的複用性。
- GRASP：低耦合、高内聚。
- 通常接納本來是基于專家模式所配置設定給領域類的職責。
- 所有GoF設計模式都是純虛構，事實上所有其他設計模式也都是純虛構。
舉例：計算商品總數量。根據專家模式計算商品總數量的職責也應該是配置設定給Order，照這樣配置設定下去商品相關的還會有：總重量、總體積、總XX，這時Order的職責就會越來越多也可能會産生額外的耦合，通過純虛構對象把這些職責配置設定出去能夠得到更好的設計。
通過虛構對象GoodsItems承擔和商品聚合計算相關的職責。
延伸：經常發現代碼中會使用Util、Handler、Service這樣的虛構類，缺點是這些類通常是單例并共用的，這些虛構類的職責會越來越多（一個Util類2000行代碼），建立和業務更相近的虛構對象才能便于了解和管理耦合關系。
6 控制器
解決方案：把職責配置設定給能代表以下選擇之一的類：
- 代表整個“系統”、“根對象”、運作軟體的裝置或主要子系統，這些是外觀控制器的所有變體。
- 代表用例場景，在該場景中發生系統事件。
相關模式：
- GRASP：純虛構
- GoF：指令、外觀
- 其他：層
控制器的核心是提供一個統一入口，避免客戶對元素内部進行耦合，很好的維護了邊界：
- api層
- 根對象
- 接口
7 多态
問題：如何處理給予類型的選擇？如何建立可插拔的軟體構件？
解決方案：當相關選擇或行為随類型有所不同時，使用多态操作為變化的行為類型配置設定職責。
優點：可擴充性強，同時不影響客戶。
訂單退款時需要計算出使用者退款金額和商戶扣款金額，在沒有新零售業務進來之前直接使用計算服務傳回的資料結構，新零售進來後資料結構未統一，需要進行适配，實作多态後的代碼擴充性很強。
在微服務架構中，比較複雜的多态問題通常會選擇增加一層去解決，如：支付網關、傳遞網關。
8 間接性
計算機學科中的大多數問題都可以通過增加一層解決，如果不行再加一層。反過來大多數性能問題都可以通過去掉一層來解決。
問題：為了避免兩個或多個事物之間直接耦合，應該如何配置設定職責？
解決方案：将職責配置設定給中介對象，使其作為其他建構或服務之間的媒介，以避免他們之間的直接耦合。
優點：實作了構件之間的低耦合。
- GRASP：防止變異、低耦合、大量間接性中介都是純虛構
注意：間接性通常用來支援防止變異。
四 架構模式
除了職責配置設定原則，還需要一些架構模式幫助我們更好的落地。
1 分層架構
在分布式系統中系統是獨立存在的，可以單獨變更而不對其他系統産生影響，但是随着業務整體複雜度的提升也帶來了一些負面影響：由于整體被分解成大量獨立的系統，随着複雜度提升系統之間的依賴關系會變的錯綜複雜，某個系統的變更會影響其他系統，同時也會産生意想不到的問題，效率也随之下降。這時就需要重新對分布式系統的邏輯架構做設計，以解決系統間的不良耦合和内聚，進而提效。
分層架構是非常實用和常見的方式，TCP/IP、HTTP、作業系統等等都運用了分層，分層的本質很簡單：通過分離關注點，達到高内聚；通過向下依賴、拒絕循環依賴、使用接口，達到低耦合。
分層架構也是存在缺點的：按照分層架構定義消息消費應該在基礎設施層，但是消息消費是為了執行某個業務邏輯，這樣就需要依賴應用層 或 領域層，如果真的這樣寫就會出現循環依賴問題。通過依賴倒置可以解決依賴問題。
2 六(多)邊形架構（洋蔥圈架構）
六邊形架構(Hexagonal Architecture)，又稱為端口和擴充卡架構風格，其中的“六”具體數字沒有特殊的含義，僅僅表示一個“量級”的意思，六邊形的定義隻是友善更加形象的了解。
六邊形架構提倡用一種新的視角來看待整個系統，該架構中存在兩個區域：“外部區域”和“内部區域”。在外部區域中不同的客戶均可以送出輸入（網絡請求、定時腳本、消息消費等），而内部區域則是處理具體邏輯的地方。
五 案例
案例1：Jpa替換為Mybatis
@Component
public class CloseOrderService {
@Autowired(required = false)
@Qualifier("rstOrderTransactionManager")
JpaTransactionManager tm;
public void invalid_order(Long orderId, Long userId, Short processGroup)
throws UserException, SystemException, UnknownException {
//其他邏輯。。。省略
// 開啟事務
DefaultTransactionDefinition def = new DefaultTransactionDefinition();
TransactionStatus ts = tm.getTransaction(def);
try {
order = orderDAO.get(orderId);
order.setStatusCode(toStatus);
order.setUpdatedAt(new Timestamp(System.currentTimeMillis()));
orderDAO.save(order);
//送出事務
tm.commit(ts);
} catch (Exception e) {
if (!ts.isCompleted()) {
//復原
tm.rollback(ts);
}
if (e instanceof SatisfiedStateException) {
return;
}
throw e;
}
}
@Transactional(transactionManager = "rstOrderTransactionManager", rollbackFor = Exception.class)
public void invalidOrder(){
}
}
@Component
public interface OrderDAO extends JpaRepository<OrderPO, Long> {
@Query(value = "sql語句", nativeQuery = true)
Long generateGlobalOrderId(@Param("userId") Long userId,
@Param("restaurantId") Long restaurantId,
@Param("seqName") String seqName);
}
變化帶來的影響：如果不出意外對Jpa的使用方式不會産生變更，意味着其相對穩定，是以在目前階段來看以上耦合是正常的也不會産生負面影響。但是在以下場景會讓我們對高耦合有很明顯的體感：大家覺得Jpa不好用，想替換為Mybatis該怎麼做？代碼中直接使用了繼承JpaRepository的OrderDAO做資料操作，由于Jpa和Mybatis的寫法不同，是以需要把使用到OrderDAO的地方都做替換：
- 調用OrderDAO的類（70多個類）都需要替換為新的dao。
- 使用JpaTransactionManager.getTransaction()的位置需要替換為MyBatis的TransactionManager。
- 使用@Transactional(transactionManager = "rstOrderTransactionManager")的位置需要改為編寫事務送出和復原的代碼塊兒，便于做灰階。
- 以上改動的位置需要增加開關做灰階。
結論：由于變更涉及到70多個類，同時事務管理器擷取方式也需要修改，其帶來的影響還是挺大的，不滿足“低耦合”原則，可以使用“多态”原則重新設計。
案例2：訂單對應的支付單應該由誰來建立？
拿餓了麼交易系統舉例，目前建立支付單的職責是由bos服務承擔（面向app的一個後端服務）的，接下我們進行分析。
支付單建立分為兩種場景：
- 建立訂單和支付單是在一次操作中完成。
- 使用者回到訂單清單頁點選“去支付”時建立支付單。
支付單建立依賴：
- 訂單号
- 支付金額
- 支付類型
- 一堆支付系統配置設定的用于識别業務的參數
注1：如果餓了麼隻會有外賣一種交易業務，目前的設計還是很穩定的，不會出現太大變化。是以識别變化點才能更好的評判目前系統設計是否合理，如：餓了麼将更新為本地生活服務公司，根據公司戰略多少能看出我們将來不隻外賣業務存在，還會有很多和本地生活相關的交易業務，這些業務會有自己的展示層（app、h5、web）同時對應會有類似bos的服務，如果有10個業務方，在支付場景就需要去對接10次，而由order做就隻需要一次（支付作為工具已經比較穩定，不會有太大變化）。
- bos比order多出識别訂單結構的成本。
- bos比order多出認知交易域業務知識的成本。需要深入了解交易狀态，這樣才知道什麼狀态才能去支付（一般是去問order服務的開發），打破了邊界。
結論：bos服務不應該承擔建立支付單的職責，由order承擔最合适。