以下內容是工作中的幾點總結，總結的上下文是在關聯式資料庫的設計環境，還請各位朋友多多發表以下自己的想法。
1、模組的最小單位根據乙個完整事務設計
2、模組的最小單位根據乙個完整流程設計
3、模組中，只能應用資料庫的連線，不能夠修改資料庫的連線，最好是在new方法中，獲取資料庫連線。
4、業務模組中的演算法如果有調整，那麼直接修改該業務模組，而不能使用繼承的方式，在子類中來實現修改，這樣做的原因是：業務模組不能作為公有的模組，在幾個版本的系統中同時使用。如果能夠同時使用，那麼這個業務模組必定是同乙個業務模組。這也要求我們在設計系統時，業務模組和系統中的功能模組不能夠編譯在一起。
5、有關member variable在類中的使用方式。
經過多年的經驗，發現通過闡述將member variable傳入方法內，是降低程式耦合度的一種方式。雖然在類的方法中仍然能夠使用member variable，但是直接使用的後果是該方法內的**不能夠直接使用。
業務設計原則 冪等設計
一 介紹 在傳統的單體應用架構中，即同乙個程序內，對於乙個函式，或者一系列的函式呼叫，結果只有兩種，要麼成功，要麼失敗 我們可以通過事務的方式控制多個函式的事務呼叫 但是在分布式架構系統中，服務與服務之間的呼叫通過網路遠端rpc呼叫的時候，除了呼叫成功或者失敗之外，還會出現第三個結果 超時，超時是分...
事務模組設計原則
廢話不多說，直接開始正題。首先從事務的原則說起 原子性 表示組成乙個事務的多個資料庫操作是乙個不可分隔的原子單元，只有所有的操作執行成功，整個事務才提交，事務中任何乙個資料庫操作失敗，已經執行的任何操作都必須撤銷，讓資料庫返回到初始狀態 一致性 事務操作成功後，資料庫所處的狀態和它的業務規則是一致的...
設計模式簡記 設計符合設計原則的業務系統之需求分析
3.9.1 需求分析 積分系統 消費積分 通過產品的線框圖 使用者用例 user case 或者叫使用者故事 user story 來細化業務流程，挖掘一些比較細節的 不容易想到的功能點。通過以上方法總結最終功能需求 積分賺取和兌換規則 比如，簽到送 10 積分。再比如，按照訂單總金額的 10 兌換...