作者 | Carole-Ann Berlioz
譯者 | Teki.D
我們已經介紹了一些基礎内容：編寫規則時不該做什麼。現在我想重點談談該做什麼。談到這個話題，我的第一個念頭，同時也是最基礎的一點，那就是：做決策。
一個常見的誤解是，決策服務隻做一個決策。當然，會有一個最主要的決策将結果值設定為true、一個字元串或計算得到一個數值。例如：
· 準許貸款申請
· 核準保險索賠
· 将一筆支付交易标記為欺詐行為
決策服務通常會做出這個關鍵決策，但它往往會附帶其他子決策。例如：
· 風險評估…
· 最好的抵押貸款産品…
· 付款金額…
· 可能的欺詐類型...
做多個決策還是一個決策
在我的職業生涯中，我見過許多不同行業的項目。它們适用于完全不同類型的決策。我時不時聽到一些人想要簡化決策結果的想法。‘某些情況下’僅僅做出一個決策是不夠的。不要假定沒有決策就等同于與其相反的決策。這種過于簡化的做法不是一個好的設計。決策服務需要做出多個決策。
業務規則通常會标記出負面的結果，例如一個拒絕的決策、疑似欺詐等。一個誘人的想法是決策服務隻在反面的行為發生時才做出響應。如果申請人沒有被拒絕或轉介，那麼他或她的申請就被準許了。既然這是顯而易見的事實，為什麼還要明确地表述呢？
在這樣的設計中，決策服務将在申請人被拒絕時傳回"已拒絕"，而當申請人沒有被拒絕時，則不會傳回任何資訊。
把糟糕的情況标注出來并不是什麼壞事。同時我個人堅信正面的決策結果也需要肯定地表述出來。決策服務所給出的最終結果都是“申請被拒絕”，這是不夠的。
如果符合申請規則，它應該能回報結果“申請已準許”。隻關注否定的結果似乎會很直覺，但沒有傳回任何結果未必就是正面的，也可能是由于缺乏資訊而無法對申請人進行審查。
不要讓決策服務做出的決策有任何的不确定性。
為什麼要同時準備正反兩面的決策？
你當然可以認為‘沒有錯誤的決定’等同于‘正确的決定’。不過我覺得這邏輯有點站不住腳。當出現例外狀況時，在這種邏輯下會得出一個肯定的結果（“申請被準許”），這會使你的業務遭受損失。如果你的決策邏輯在中間步驟失敗了，不要忽視了這一資訊。
不要是以臆斷我不信任業務規則。顯然，業務規則會忠實地重制您所建立的決策邏輯。我擔心的是資料會随着時間的推移而改變，既定的決策邏輯也會同樣改變，而且很頻繁。
不要想當然地認為所有可能的路徑都被覆寫了。目前你的規則可能會檢查是否所有必需的資訊都已經提供了。假設第二天你的決策服務需要一個新資料，而負責該資料相關規則的業務分析師忘記提前檢查，缺少此資料時，将無法做出決策。最終你會得到許多一開始就無效卻被準許了的申請。
簡而言之，我強烈建議為例外事件做好準備，不要讓它在不經意間發生。一定要清楚地表述你的決策。如果申請沒有被“拒絕”或“轉介”，則添加一條規則将狀态設定為“已準許”。
如果遇到這些無法做出決策的情況，隻需要相應地更新你的決策邏輯。另外，這會大大增加在品質檢查時發現這些問題的機會。你也不希望在決策邏輯部署到生産環境後還出現混亂。這就是關于做決策的101規則。
原文連結：https://www.sparklinglogic.com/making-decisions/
聯系客服号擷取更新文檔