本文来源于公众号：勾勾的Java宇宙（微信号：Javagogo），莫得推广，全是干货！
原文链接：mp.weixin.qq.com/s/ccyw4jKFb…
作者：刘海丰
大多数研发同学对自身技术发展的认知，仅停留在学习了哪种新的技术，掌握了哪种新的开发框架，觉得这样就能把技术做好，就能成为架构师。
可是现实情况是：你觉得自己的技术能满足应聘部门的要求，可还是面不到想要的职位。
原因是什么呢？
很可能是因为你没有达到一个高级研发或者是架构师该有的思维层次。
我曾面试过一名研发工程师，称自己在重构一个负责交易流程的系统时，将其拆分成报价系统、促销系统，以及订单系统，而当时他们只有两个人负责交易系统的开发工作。
针对他的经历，我的问题是：
你们只有两个人负责这个交易系统，为什么还要做系统架构拆分？而且拆分之后会带来其他的复杂度，你是怎么考虑的？
系统拆分的架构设计问题在面试中很常见，如果你是这名应聘者，会怎么回答呢？
很多研发同学一提到架构设计就说要做拆分，将一个系统拆分成两个系统，将一个服务拆分成两个服务，甚至觉得架构就是做系统拆分，但其实并不理解拆分背后的底层设计逻辑。
那这个问题的底层逻辑到底是什么呢？
1. 为什么做架构拆分？
通常最直接目的就是做系统之间解耦、子系统之间解耦，或模块之间的解耦。
2. 为什么要做系统解耦？
系统解耦后，使得原本错综复杂的调用逻辑能有序地分布到各个独立的系统中，从而使得拆封后的各个系统职责更单一，功能更为内聚。
3. 为什么要做职责单一？
因为职责单一的系统功能逻辑的迭代速度会更快，会提高研发团队响应业务需求的速度，也就是提高了团队的开发效率。
4. 为什么要关注开发效率？
研发迭代效率的提升是任何一家公司在业务发展期间都最为关注的问题，所以从某种程度上看，架构拆分是系统提效最直接的手段。
所以，架构拆分其实是技术上提效的一种手段。
认识到这一点后，就不难理解为什么很多架构师在做系统架构时会做系统设计上的拆分，甚至会有很多研发同学认为架构的本质就是拆分了。
我们来看看当时的候选人给出了什么样的回答？
他说出了四个层面。
-
从订单系统层面来看，由于交易流程中的订单系统相对来说业务稳定，不存在很多的迭代需求，如果耦合到整个交易系统中，在其他功能发布上线的时候会影响订单系统，比如订单中心的稳定性。基于这样的考虑，需要拆分出一个独立的子系统。
-
从促销系统层面来看，由于促销系统是交易流程中的非核心系统，出于保障交易流程稳定性的考虑，将促销系统单独拆分出来，在发生异常的时候能让促销系统具有可降级的能力。
-
从报价系统层面来看，报价是业务交易流程中最为复杂和灵活的系统，出于专业化和快速迭代的考虑，拆分出一个独立的报价系统，目的就是为了快速响应需求的变化。
-
从复杂度评估层面来看，系统拆分虽然会导致系统交互更加复杂，但在规范了 API 的格式定义和调用方式后，系统的复杂度可以维持在可控的范围内。
这样的回答很好地表达了应聘者对系统设计的思考与理解。
因为他说出了原有系统中关于订单、促销和报价功能耦合在一起带来的实际问题，这是立足于点；又从交易流程的角度做系统设计串联起三个系统的拆分逻辑，这是连接成线；最后从复杂度和成本考量的方向夯实了设计的原则，这是扩展成面。
欢迎大佬们关注我的公众号：勾勾的Java宇宙（微信号：Javagogo）
