筆者本週遇到了十分棘手的業務需求，在反覆的幾次重構之後，希望能總結一點可以用於下次參考的經驗
bp發起打分時，我需要對 這個考核目標中包含的 績效考核指標 打上具體的完成值，並且通過完成值和這個指標的得分規則 ——-計算出相應的分數，
績效考核的指標有 財務指標，客服指標，主觀指標這三類，考核的週期有月考 ，年考
財務指標和客服指標屬於是客觀性質的指標，所以他們的完成值是其他系統計算的，每個月都有具體的數值，
於是我需要對客觀性質的指標從其他系統對接過來，並且對於年考的指標，需要自己計算一番，
1.主表： examine_goal ——績效考核目標表
包含字段 id ，empcode ，startime， endtime
2.副表： goal_target_info——-考核指標表
id ，eid, datasource, weight, score_rule, finishedvalue,score,type,id ,costcode,weight,cost_target_month_data———每月成本中心資料
資料表： customer_target_month_data——–客服指標每月資料
month ，datasource，finishvalue，empcode
首先我們可以把這個業務分解一下，
1. 取出這個考核人的 list《客服指標》 list1；
2. 獲取到客服指標的完成值finishvalue
3. 根據finishvalue+得分規則 獲得 實際得分
1.任何時候動手之前，一定要有乙個清晰的完整的思路，
2.一定不要怕麻煩，最小的細節 比如取名不規範，它會給你以後造成極大的麻煩，
3.將乙個複雜而龐大的功能分解成乙個乙個的小模組去實現，通過事先構想出的思路，將每一步需要完成的點 當成每乙個階段的目標，
4.不要想著一次就能較好的實現乙個複雜的功能，第一次嘗試時，你可以寫的非常複雜，冗餘，不完整，這都不是問題，因為它肯定可以為優化時，提供非常好的思路和 模組思路，讓你更好的去完成抽象和切分，
5.切記不要在乙個serviceimpl類中 寫過多的 private方法，就是要不怕麻煩的把其他service的功能分開，不要出現一層呼叫下一層的，因為日後維護會十分耗費時間，
6.乙個人一天的精力絕對是有限的，當被複雜的業務邏輯整的陷入僵局和死胡同後，就不要再坐著了，需要出去走一走，喝一喝水，頭腦一直緊繃中，會死的很快，會非常容易累
7.當多表鏈結容易讓人迷糊時，你需要的時 適當的分解 複雜度，把你想要的 結果集 封裝入乙個vo類中也是十分有效的方法，
1. 我要獲得 客服指標的完成值， 怎麼查詢到 呢
明顯 乙個 month ，empcode 才是核心
select
sum(finivalue)
from
customer_target_month
where
month 在乙個區間
empcode=乙個值
datasource=乙個值
group
by empcode
於是我們將上述的三個條件作為 另外乙個sql的結果集，構成組裝成這樣乙個 結果集就行
select
a.startime，b.endtime
c.empcode, d.datasource,
from
exmain_goal a
left
join goal_target b
on a.id=b.e.id
where b.type='客服指標'
如果 你不想把這兩個sql 組合在一起，那麼，
你就講 條件 組合成乙個 vo
list voparamlist= new arr…
vo的屬性：
private
string datasource
private
date startime
private
date endtime
private
string empcode
select *
from
(target_month 那個結構sql )a,( 查詢出vo的 sql) b
where
複製之前的結構即可
分解模式 按業務領域分解模式劃分微服務
本文說明如何通過業務領域分析和ddd將大型複雜的應用程式劃分為一組微服務。使用微服務架構開發乙個大型複雜的應用程式，我們需要將應用程式細緻，合理地分解為一組鬆散耦合的微服務。微服務架構的目標是通過實現持續交付 部署來加速軟體開發。通過領域驅動設計 ddd 設計與子域相對應的服務。ddd通過分析問題空...
日誌分析 六 業務異常日誌分解
1.初步分離 業務系統在執行期間會丟擲來一些執行期異常日誌，監控這些日誌，過濾多餘其它日誌，然後給予相應owner告警就成為異常監控的目標之一。logstash配置如下 input filter if type exception if multiline not in tags output 刪除...
業務流程為主線的分解結構
業務流程為主線的分解結構 這種結構是以業務流程為主線索的，也就是按 事 的角度進行分解。它對於聯機事務處理系統 管理資訊系統而言是非常適用的方法。程式結構為主線索的分解結構 適用於問題域不複雜，或者系統與問題域關聯性不強的情況下，例如工具軟體 面向裝置的嵌入式系統等 基於場景的分解結構 對於決策支援...