领域对象细化分解方法总结

以账号这个领域对象为例。账号是非常大的主题，里面包含了很多的东西，账号的基本信息、实名认证、计费Profile等等，这些属性都可以关联到用户。如果这些业务熟悉不进行分类组织，都塞在账号这个笼统对象就不够灵活。那么怎么去分类？这个是不是有一些套路？

• 根据属性的访问频率去拆分，访问最频繁的可能是客户的基础属性，比如ID、PK等等。一些客户的补充信息可能访问的频率就少了，可以抽象成基本属性以外的内容
• 可以根据属性的修改的频率去拆。比如用户的基本属性和用户的账户（是否欠费）两个变化的频率差别很大，就不适合放在一起
• 从触发属性变更的业务场景出发。比如结算、注册这些场景，就各自有不同的对应的业务属性。

通过这些维度去观察和分析我们的对象，我们能把很复杂的业务对象细化分解成更细粒度的业务对象（基本属性、认证、BillingProfile），并彼此关联起来。

完成了业务对象的细分以后，后面我们再要看的技术方案是分解出来的业务对象是不是要打散落地到各个独立的业务域中。这个时候我们主要balance的可能是以下几方面的问题：

1. 细分后的业务对象的创建和更新的频率如何，是不是要几个对象同时更新的情况，分布式的事务如何保证。
2. 细分后的业务对象属性的创建和更新的客户体验怎么保证，比如billing profile 跟账号基本信息的更新维护是在一个步骤里面维护还是分不同的tab页去维护

如果以上问题可以保证，我们可以在各个业务域中独立去落地归属到各个业务域的客户属性，这么做的一个架构优势就是 业务域降低了对外的依赖，例如， 结算域高频率依赖的Billing Profile都在内部发生，可以比较好的做性能优化，减少了对账号中心的依赖，属于高内聚低耦合的设计。