聊一下domain和entity

這段時間在負責海外事務，今天帶着客戶端走海外商店的支付流程。由於在國內接的大多數是渠道聚合的SDK，客戶端就不多關注支付業務流程，只是按照之前的接的demo而後按照渠道提供的參數就直接上了。先po一張業務流程圖，而後再把話題撤回來。

簡單的畫了一下流程圖，從流程圖中能夠看到，服務端在整個支付流程上作了不少次遠程調用。由於Store提供出來的API是基於OAuth2.0的，對於AccessToken進行了封裝並根據它的有效期進行自動更新，進而有了今天的話題。

其實AccessToken這個數據容器是一個很小的東西，它裏面的數據成員基本上就是Store返回的數據參數，但後續我又須要對它的過時時間進行監控。因此，AccessToken的對象會在遠程調用的結果參數上再加createTime這個成員變量。很快就會有了如下這個包結構：

而後基於回調對FooAccessToken進行序列化操做。問題來了：這樣就能夠了嗎？

我聞到了代碼的壞味道：

1.FooAccessToken是否是須要承載領域模型這麼重的職責？而且在橋接SDK的工程上，咱們是基於貧血模型開發的，不須要對實體進行simulate，只需關注數據流向就行了。

2.基於回調對FooAccessToken進行序列化的操做直接將封裝的AccessToken耦合到了傳輸層，這不利於後續的改動。

對代碼文件在此提煉，進而有了如下的改動：

雖然看起來「畫蛇添足」，但在代碼層次和語義上更清晰和明瞭了。基於貧血模型，業務對象更傾向爲數據載體，賦予對象行爲反而不太合適。業務對象不該該直接跟傳輸對象耦合在一塊兒，在傳輸層須要對外部進行隔離。