這段時間在負責海外事務，今天帶着客戶端走海外商店的支付流程。因為在國內接的大多數是渠道聚合的SDK，客戶端就很少關注支付業務流程，只是按照以前的接的demo然后按照渠道提供的參數就直接上了。先po一張業務流程圖，然后再把話題撤回來。
簡單的畫了一下流程圖，從流程圖中可以看到，服務端在整個支付流程上做了很多次遠程調用。因為Store提供出來的API是基於OAuth2.0的，對於AccessToken進行了封裝並根據它的有效期進行自動更新，進而有了今天的話題。
其實AccessToken這個數據容器是一個很小的東西，它里面的數據成員基本上就是Store返回的數據參數，但后續我又需要對它的過期時間進行監控。所以，AccessToken的對象會在遠程調用的結果參數上再加createTime這個成員變量。很快就會有了以下這個包結構：
然后基於回調對FooAccessToken進行序列化操作。問題來了：這樣就可以了嗎？
我聞到了代碼的壞味道：
1.FooAccessToken是不是需要承載領域模型這么重的職責？並且在橋接SDK的工程上，我們是基於貧血模型開發的，不需要對實體進行simulate，只需關注數據流向就好了。
2.基於回調對FooAccessToken進行序列化的操作直接將封裝的AccessToken耦合到了傳輸層，這不利於后續的改動。
對代碼文件在此提煉，進而有了以下的改動：
雖然看起來“多此一舉”，但在代碼層次和語義上更清晰和明了了。基於貧血模型，業務對象更傾向為數據載體，賦予對象行為反而不太合適。業務對象不應該直接跟傳輸對象耦合在一起，在傳輸層需要對外部進行隔離。