思考乙個業務系統，物，行為都可以設計 為實體。最重要的是從人角度出發，
行為流程角度：
1. 流程
2.不同型別同乙個流程點
實現：不同型別就是不同的策略，可能輸入的引數都不同。通過介面來規範。 通過filed來接受屬性。避免了context類的出現
每次執行時 new 物件，賦值引數，然後 execute。
資料庫實體關係角度：
1. 要盡量的抽象，不要把上層，前面業務id放入到下游。如果表進行了組合，切記使用外來鍵id關聯，查詢也要通過這個，切不可用unique去限制，也可以限制，日後可放開。
例如：訂單id支付記錄上，另外tradeid和orderid不要設定1對1關係。
有些支付並不是針對orderid的。
實體表要盡量組合。 例如pay，可以和order對應的表組合成給pay支付的。可以降低上層開發量。
如果只需要主表資料，hibernate自動幫你路由到對應表。對上層業務來說更通用了。不然新增加乙個業務就要新增加do，dao，這個會降低業務可擴充套件性。
表組合有利於業務下層 ，但會增加查詢次數。
2。實體關係如果一定要unique，那麼最好是泛華的，不要具體業務。
層級和 型別:
1. 底層的型別肯定更少,比如 (支付,退款,*** . 然後才是渠道,子渠道.)
乙個支付對應著上層的n 個 業務type .提供查詢介面, trans_id + biztype. 更好的方法是. 將 biz_type 和 trans_id **上.
這樣直接儲存,查詢也更方便.
對應業務也知道給支付的流水號是啥.
2. biztype 不用列舉值,而應該用列舉類,列舉類維護值,介面內可見,是內部類.
可自定義的SSO單點登入高可擴充套件設計方案
我們通常所使用的的單點登陸工具cas以及keycloak等，可以在一定的環境下做到多個應用統一登入的功能，確實提供了不少的方便，但是如果是面臨多個單點登入工具以及本地登入的結合將如何對接呢，大公司或許只有乙個穩定的單點登入平台，但是對於小公司尤其是三方公司就不一定了，針對這一情況，特意提出了乙個可定...
可擴充套件 高可用服務網路設計方案
可擴充套件 高可用服務網路設計方案 email sery 163.com email 定義 可擴充套件 在使用者訪問數量快速增長的情況下，不終止現有服務來擴充套件系統的容量。比如 web伺服器目前已經不能接受更多的使用者訪問，可以在不停止服務的情況下增加第 2臺伺服器，甚至更多的伺服器，而且新增伺服...
可擴充套件的檔案同步設計
在老的cms系統中通過新配置的同步系統，對cms生成的檔案進行同步。方便對機器新增的擴充套件，新新增的機器首先執行同步初始化的功能模組，此圖暫時沒有加上。在同步模組中進行配置源與目標伺服器的服務模組url。cms的新聞新增，修改及刪除需增加同步函式，以使得新聞新增修改和刪除的動作記錄到同步表中。同步...