这段时间在负责海外事务，今天带着客户端走海外商店的支付流程。因为在国内接的大多数是渠道聚合的SDK，客户端就很少关注支付业务流程，只是按照以前的接的demo然后按照渠道提供的参数就直接上了。先po一张业务流程图，然后再把话题撤回来。
简单的画了一下流程图，从流程图中可以看到，服务端在整个支付流程上做了很多次远程调用。因为Store提供出来的API是基于OAuth2.0的，对于AccessToken进行了封装并根据它的有效期进行自动更新，进而有了今天的话题。
其实AccessToken这个数据容器是一个很小的东西，它里面的数据成员基本上就是Store返回的数据参数，但后续我又需要对它的过期时间进行监控。所以，AccessToken的对象会在远程调用的结果参数上再加createTime这个成员变量。很快就会有了以下这个包结构：
然后基于回调对FooAccessToken进行序列化操作。问题来了：这样就可以了吗？
我闻到了代码的坏味道：
1.FooAccessToken是不是需要承载领域模型这么重的职责？并且在桥接SDK的工程上，我们是基于贫血模型开发的，不需要对实体进行simulate，只需关注数据流向就好了。
2.基于回调对FooAccessToken进行序列化的操作直接将封装的AccessToken耦合到了传输层，这不利于后续的改动。
对代码文件在此提炼，进而有了以下的改动：
虽然看起来“多此一举”，但在代码层次和语义上更清晰和明了了。基于贫血模型，业务对象更倾向为数据载体，赋予对象行为反而不太合适。业务对象不应该直接跟传输对象耦合在一起，在传输层需要对外部进行隔离。