持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第15天，点击查看活动详情
从业务域分析可见，交易涉及buyer、seller、平台、物流等多方；涉及多个正向、异常流程；不同类型的商品的交易流程也会有所区别。综合这些信息来看将所有的业务放在同一个系统中，必然造成系统臃肿，耦合严重，功能相互影响，不方便扩展，优化困难。
如果过多设计系统，系统拆分的过于细小，必然对开发速度、维护成本产生影响。如何划分系统呢？
仅讨论业务架构常见原则，为讨论交易系统业务域划分准备。
3.1.1 没有最好的设计，只有最适合的设计
业务发展的不确定性高，流量小或者中短期内达不到非常高的量级时，越是能以最小的成本达成业务需求的设计，越是优秀设计。如开发成本只需一两周，能满足半年到一年的设计很多时候比一个开发成本需要三四个月，能够满足5年需求的系统更加适合。且不说业务一定能发展的好，后者一定能排上用场；长的开发周期必然会拖累业务的快速发展，产品也不会任你胡来。
产品应该小步快跑，系统设计与开发也应该是小而快，避免过度设计。
3.1.2 架构要与业务水平、技术人员的水平匹配
以淘宝、京东的架构来为一个初创公司架构系统显然错误：
- 团队人员数量、质量跟不上这些公司
- 请求的流量、业务复杂性不如他们
强行使用他们的架构会严重降低开发速度，增加开发、联调、测试、发布等环节的成本，浪费服务器资源、增加维护成本等等。
3.1.3 要能够水平扩展
上面建议不要过度设计，但若业务飞速发展，如何够满足满足业务的需要，让业务不受技术的拖累？水平扩展，通过增加服务器来为重新优化设计系统提供缓冲时间。
很多开源软件提供了不少方便水平扩展的技术和中间件，例如dubbo、zookeeper、MQ、缓存等。系统应该做到以下几点，以便简单的水平扩展：
- 尽可能降低db层的压力，因为增加业务服务器比增加DB实例要简单方便很多
- 服务器无状态，或者自动管理状态。做到这样部署1台服务器和部署10台开发成本几乎一样
- 尽可能使用分布式技术。例如：如果锁定资源，要尽可能使用分布式技术，而不要使用单机技术，否则增加服务器就可能产生不可预知的问题。
3.1.4 要解耦、要易扩展
解耦、易扩展是为了降低维护成本，降低不同业务之间相互影响，提升系统可靠性、可用性的一种手段。面对业务发展不确定性，保证系统具有这两个品质，可以为以后流量快速增长、业务转型、多业务接入打下一个良好的技术。
