为什么项目初始阶段不适合做架构设计？
因为技术都是为业务服务的，在任何时候，特别是业务从0-1的时候，都是争分夺秒抢占市场的，不会留给程序员很多时间去好好设计。
资源永远是有限的，在业务初始阶段，与其花费大量成本打造一个支持高可用、高并发、高吞吐，又灵活支持业务变更的完美系统，不如小步快跑，提出想法，快速实现，上线验证，反馈迭代，这才符合今天商业的运作方式。
而架构是看不见的，架构再好不能反映到产品形态上。我们总能找到比架构更优先的事情——用架构设计的时间，换来按钮顺序的调整，也是对用户有帮助的，是值得的。但对唯一能看见架构的程序员来说，日益屎化的代码，无疑是恶心的。
只有当系统的逻辑错综复杂、系统的各个模块盘根错节，整个系统的变更成本高到一定程度时。一个更优的系统架构才会被渴望。
所以任何事情的缘由只是ROI罢了。
那项目初期应该做什么？
假如真给时间你设计，恐怕也不能设计出长久可用的架构。因为我们的业务是不明确的，自然，架构也不能明确。
这里有一种场景例外，业务不会完全相同，但同样是电商业务，拼夕夕、淘宝、抖音电商的系统设计，也会有相通之处。这就是我们为什么要招聘有相关行业经验的技术人员。他们踩过的坑，我们不要再踩；他们知道模型要怎么设计才能灵活地支持后续可能的业务；他们知晓类似的系统最终会演化成哪几个子系统，等等。
那听你这么说，你很勇哦 岂不是我们一开始就不用思考，直接咔咔上手呢？
细心一想，只是业务部分的架构我们不能明确，所有软件系统共有的部分，我们还是可以明确的。比如：分层思想、单一职责等，将相同的逻辑放在一个地方，将相同职责的模块放在同一个层级。又比如先校验参数再做数据转换，再存入数据库，任何节点有错误，就返回。
以上这些各种框架实际上都能够完成。所以一开始，选择一个大概能适配系统复杂度的框架，进行开发就好。至于在系统上开发的业务逻辑，我们也注意些不要到处乱放，都收敛到同一处地方，这点很重要！至于这个地方是否合理，不是特别重要，因为只要逻辑在一处，以后想要对它进行改动、重构、迁移，测试，灰度的成本都十分小。
重构时做什么？
当一个系统需要重构时，基本上业务已经成型了，在支持现有业务的基础上，再去预留灵活度，去设计满足今后3-5年业务发展的一个架构。想要将此事变得靠谱，还需要在设计的过程中多和产品、运营等业务人员沟通，理解业务发展趋势；设计出来的架构，需要进行推演，比如：现在关系是一对一，有没有可能一对多，如果要改，改动困难吗？又比如：现在我们只有一个业务方，如果之后要支持多个怎么办？不同业务方有不一样的校验规则和分发渠道又如何满足？
总结
系统初始阶段，全组明确一个框架，在此上开发，当业务逐渐明确后，则有意识地按照业务模块进行逻辑的落地，当迭代成本变高了，或者某一个业务有必要单独演进时，则需要进行架构重构，无论是系统上还是业务上。
