我一直很认同一句话：架构一定要随着业务的发展进行演进，所以在着手处理之前，都需要思考4个问题：
架构演进前的4个问题
（1） 本次架构演进为了解决那几个业务或技术问题？
避免为了炫技而动架构，并且作为本次架构演进是否成功的验证标准。
（2）解决这些问题是否迫在眉睫？
如果不紧急，那么可以考虑先出方案写Demo，然后到一定的时间或业务节点在做处理。
（3）除了架构演进外，用别的方案能否起到同样的作用？
如果可以的话，建议采用别的方案，避免造成结构性的破坏。
（4）需要投入多少人来做，架构演进的边界在哪里？
我们毕竟是商业公司，不是开源组织，不能不计成本，无休止的进行下去，需要有一个计划和目标。
基础组件层抽取
为了清晰的说明以上4点，我们举个很简单的例子：最近一次的架构演进是基础组件层的抽取。作为架构师我们来回答以上4个问题：
（1）本次架构演进为了解决那个或那几个业务问题？
问题1： 我们目前同时维护两个APP（更美用户版和更美医生版），而两个APP的很多地方都是很像甚至一样的（因为医生版的代码大部分都是从用户版拷贝过去的），那么这就造成一下几个问题：
用户版发现了一个Bug，那么对应的医生版的APP也得改，还有可能改出新的Bug。
相同的业务流程做了同样的修改后，两边都需要同步，甚至有的时候，由于分别维护，所以某些代码已经产生了版本的差异，所以问题就从枯燥的代码的拷贝粘贴到需要仔细检查一下业务逻辑，极有可能出错。
所以我们搭建了基础组件层，将基础组件（如：网络，缓存，公用控件，工具，统计等等）抽取出来给两个APP进行公用，从而有效解决了问题。
问题2： 由于公司的人比较少，Code Review的力度不够，所以我们需要将公用控件和底层逻辑在层维护，从Gitlab的权限上进行隔离，保障这部分代码由经验丰富的工程师来维护，降低风险。
（2）解决这些问题是否迫在眉睫？
问题1：紧急，医生版迭代的速度越来越快，如果不尽早进行架构演进，那么问题将会越来越多，以后演进的成本会更大。
问题2：一般，我们的工程师有良好的习惯，一般在有任何底层代码变更需求时，都会先和架构师进行沟通，避免擅自修改带来的问题。
（3）如果不做架构演进，用别的方案能否满足业务需求？
暂时没有发现别的方案。
（4）需要投入多少人来做，架构演进的边界在哪里？
大约投入了2个人1个迭代的时间，关于抽取哪些内容，之前已经制定了完整的计划和目标，甚至我们先抽取出了最常用的网络层来做可行性验证。
嗯，看上去确实不错，4个问题都回答的很好，不过好像还差一块，架构演进完毕后的一段时间，我们需要从业务工程师那里了解一下新的架构是否真的像自己想想的那样牛X，所以还有一件事就是架构的使用反馈。 通过自业务工程师的反馈，你不仅可以了解自己的架构是否达到了目标，而且能够知道自己的架构是否足够的优秀和接地气，是的，就是接地气，可能看上去土但是很实用。
业务组件层
OK，那么我们再尝试用上面的方式来讨论一下我们下一步要做的业务组件化的架构演进
（1）本次架构演进为了解决那几个业务或技术问题？
目前我们的App的代码都是在一个工程里开发的，在人比较少，业务发展不是很快的时候，这样是比较合适的，能一定程度地保证开发效率。
目前业务发展速度倍增，代码量和开发人员也逐渐增多，这时单一工程开发模式就会显露出一些弊端：
- 耦合比较严重（因为没有明确的约束，「业务」间引用的现象会比较多）
- 任何人都可以修改任何代码，分工不明确，容易导致意想不到的错误
- 业务方的开发效率不够高（只关心自己的组件，却要编译整个项目，与其他不相干的代码糅合在一起）
- 团队规模扩大的时候Git分支增多，提升管理难度
为了解决这些问题，就采取了「业务组件化」策略。它能带来这些好处：
- 加快编译速度，只用编译Example工程和依赖的基础组件
- 自由选择开发模式（MVC/MVVM/MVP）
- 自由选择开发语言（Swift/ObjC/Java/Kotlin）
- 方便 QA 有针对性地测试，没有改动的业务组件不需要QA覆盖
- 提高业务开发效率，只需要关心自己的业务
（2）解决这些问题是否迫在眉睫？
看上去还行，虽然目前业务发展速度毕竟快，但是目前团队人数并不多，代码量还在可控范围内，所以目前并不急迫。可以先研究方案，写写Demo做做验证。
（3）如果不做架构演进，用别的方案能否满足业务需求？
从调研的结果看，这个是目前主流方案，用其他方案是否可行还待进一步论证，好在我们并不着急。
（4）需要投入多少人来做，架构演进的边界在哪里？
预计需要2个人，3 - 4个迭代的时间，将主体业务都拆分出来，原则上主应用中不应该包含任何业务代码。
