最近遇到一個場景的問題：多個系統共用同一個枚舉時的維護問題。在網上，按照關鍵詞：從 枚舉 到 數據字典 ，一路搜索過去，遇到幾篇不錯的文章。整理一下，類似於做個綜述。
從 問題 以及 直觀的解決方案 來表述問題的演變過程：
1. 在DB設計中，某個字段的取值范圍只會是 某幾種值，比如性別只會取：男 or 女，我們如果想在后續校驗這個字段的值是是否規范要求的怎么辦？ 單獨拎一張類型表出來，在這張表中就設定這個type只能是某幾種value，后續在代碼中拿這張表的數據作為參考往業務表中插值。這種解決方案，我們一般稱之為 [類別表]。 2. 在做后台管理系統開發時，經常會遇到很多下拉select選項，這些下拉select的值一般是固定的幾個，如果按照上面的思路，我們要建很多 [類別表]。不想建很多類別表，怎么辦？ 做一張公共的類別表，這張表里面存按照code區分不同類別。這種解決方案，我們一般稱之為 [數據字典表]. 一般我們還會在后台系統中設計一個 數據字典菜單功能，方便修改字典。 3. 在java代碼系統（或強類型語言）中，我們要從DB中讀取數據字典放到內存中，不然每次都就去DB中做查詢，多浪費性能啊。但是放到內存中，我們用什么類型來存放呢？ Map or Enum，我們一般會用上面這兩種類型。請注意這里都是從DB -> java對象，比如拿枚舉來說，如果做要做任何的 值的比較是沒法做的，因為一開始enum可能是一個空的enum然后讀取DB動態加載了枚舉項，所以是沒法直接拿枚舉的字面項去使用。 做判斷必須是 字符串 轉 枚舉，然后枚舉和枚舉之間的比較；又或者是 枚舉 轉 字符串，字符串和字符串之間做比較。 4. 如果一個公司有很多系統，因為要做數據標准化，所以必須限定都是用同一套數據字典，而且為了編程的便利性，我們要求直接將 DB數據字典 加載為 java內存里的enum，這時怎么處理呢？ 這時可以是一個公共二方包sdk來做這件事兒，還是每個系統都可以自己獨立加載。每個系統在啟動時都通過公共SDK，來動態刷新二方包中定義的枚舉項。 這樣限定了整個公司的所有系統不僅要 數據字典的值要一致，而且用到的枚舉值也必須一致。 5. 如果后續某個字典項的值修改了，是否要通知到所有依賴SDK包的下游系統做聯動發布呢？ 這個問題，也是分布式系統建設中，如何建立並維護一個公共配置中心的問題一樣類似的思路，如果數據字典的值在DB中做了修改那么可以通過kafka等異步消息的方式通知到所有下游系統中去。下游系統consume到消息時做枚舉的動態加載操作。
上面幾個解決方案以外的思考：
1. 不能直接利用枚舉的字面值進行比較是個限制。 且java的枚舉這種數據結構類型的語義是，靜態的、固定的、不易修改的一類數據。所以，在有些文章上會說，動態加載枚舉項是破壞了代碼的可讀性。 2. 版本的考慮，數據字典的數據應當是不能updae，不能delete，只能insert的。因為歷史數據中已經使用了之前的枚舉項。 3. 為什么不直接用數據字典緩存SDK包呢？想的是，通過枚舉還是能起到一些強類型語言的優勢。
比較不錯的幾篇文章：
1. http://www.talkwithtrend.com/Article/220231
這篇文章比較宏觀，從公司的數據標准化建設的角度，來談這個問題。解決方案可總結為，基於配置中心做本地可熱加載的查詢緩存系統。
2. https://blog.claves.me/2019/03/12/dict_enum/
https://blog.csdn.net/weixin_42476601/article/details/84261992
介紹了數據字典的概念，枚舉的概念。
3. https://blog.csdn.net/qq_35530330/article/details/85647826
介紹了動態加載java枚舉項的方法。