自顶向下 VS 自底向上，代表了软件开发的两种主流方式，前者指从应用的最顶层开始设计，一直做到最底层的代码；后者指从应用的最底层编码开始设计，逐步开发出整个软件架构。

自顶向下属于典型的瀑布开发模式，讲究的是先确定好系统的架构模型与规范体系，明确模块之间的依赖关系，就像计划经济一样，好处是有明确的开发指导思路，缺点是不适应快速变化的外部需求；

而自底向上属于典型的敏捷开发模式，先构建出一个原型，再不断的去循环优化和改进，就像打仗一样，首要目标是验证系统的可行性。

对于大多数工程师而言，这两种开发方式并无太大的区别，但落地到具体的场景，那么方法的区别还是会有明显的不一致。典型的例子就是ERP VS CRM。

|0x01 B端的架构认知

ERP系统是企业资源计划的简称，一般指企业的管理信息系统，最有价值的作用在于改善企业的业务流程，提高核心竞争力。

这么理解其实是有些模糊的，那么给一个具体的例子来看待一下。

过去企业的费用报销，大家都是通过开发票-贴发票-领导签字-财务审批等流程一步一步走下来的，发票这个东西，餐饮与出租车的不同，北京与上海的不同，不仅核对金额非常费事，而且存在虚开发票等难以鉴别的造假场景。

所以很多公司现在的费用报销都会实现线上化，比如跟滴滴、酒店直接进行核算，不仅员工报销省事了，企业也能够降低成本、避免费用造假。

如果这时候让你来设计费用报销的系统，拆解整个系统架构并不复杂。遵循瀑布式开发流程，从报销的每个流程入手，设计好子系统：流程管理、费用核算、人员组织，等等，最后编码实现具体的模块，就是一个完美的自顶向下的开发模式。

但是计划赶不上变化快，公司规模扩张了，收购了很多小公司，成立了集团。既然大家都在一片屋檐下共事，那么自然系统也要兼容到一起。

这个时候，尽管系统需要整合到一起，但每个公司都有自己独立的报销流程，人员也不共享，单纯的定制开发已经难以适应需求了，这时候，才猛然发现，“多租户技术”才是这种软件架构的核心方法，而适应这种技术，几乎所有的子模块都需要进行重新开发，非常痛苦。

这种ERP产品开发过程中，各种在架构上的纠结，体现了B端产品的一个特点：“持续演进”。历史的架构有它存在的意义，但企业又不会一成不变，那么如何兼容和适应未来可能发生的变化，减少架构的频繁重构，就是一种考验技术人员“架构认知”能力的现实场景了。

如果软件遵循传统的方法，那么架构师出整体设计，工程师照着实现就行。但在互联网化加速的今天，每位工程师，就不仅仅是实现了，同样要求比较高的架构能力。

B端的架构认知，是先有业务沉淀，再有架构设计。

|0x02 C端的架构认知

CRM一般指客户关系管理，指企业为提高核心竞争力，利用信息技术为客户创造创新价值的系统。CRM的架构演进与ERP类就不同，因为不是面向企业管理的，而是面向客户增值，因此怎样能够提高利润，或者怎样可以提高运营效率，就可以怎么来做。

随着商业模式的不断进步，突然有一天，我们会发现，原有的功能虽然还是那些，但效果不一样了。典型的特征就是新用户的成本持续增加，ROI明显下降，这个时候我们就需要不断思考，商业模式发生了怎样的变化，我们又需要怎么做。

所以当今的CRM系统变得越来越复杂，但对于架构的挑战，主要来自于新模块的开发，而不是旧模块的重构。

因为原有的商业模式没有变，我们需要拓展新的商业模式。当我们依据行业主流的开发经验，做好架构的设计之后，通常情况下不会有大的变更，更多的精力会放到新业务的探索上。

另外，与B端不同的是，C端你无法一上来就想好怎么做，因为商业模式是快速变化的，而企业管理就不会变得很频繁。所以C端的成果，大多数是在不断的试错中沉淀下来的，一旦可行，后续的变动就不会很大。

C端的架构认知，是先有架构设计，再有业务沉淀。

我们每个人都认为，未来是数字化的时代，但数字化究竟是个怎样的样子，现在大家都是在探索阶段，对传统行业的数字化改造，也需要更多的行业经验，才能做得好。

例如传统的制造业，每一步工序，每一台机器，都是在长期的实践中，逐步沉淀下来的最优解决方案。你不能一上来就按照互联网的方式，快速试错，那样只会把企业搞垮。因此对于这一类行业的数字化，就不仅仅需要互联网的开发经验了，还需要传统制造业的经验。