设计一个系统，一方面是架构上的设计，一方面是功能上的设计。这两者其实不能严格分离开，但是可以从下面这个角度来进行一下区分。架构可以理解为怎么让用户来使用这个系统；功能可以指怎么来满足业务上的需求。比如说我在架构上使用一个 transit gateway + 2 VPC(2AZ) 来保证用户可以通过网络访问服务并且在单 AZ 不可用的时候依然可以访问；我使用了 CDN 做加速，redis 做缓存来保证同时可以有 XXX 个用户来访问我的系统；我把变更数据都放到了 Kafka 里，这样我的下游系统就可以收到我的更新。这部分主要解决的是“能不能”的问题，也就是这个服务能不能被别人（无错的、安全地、高效地）访问到。这类的设计看上去非常的 technical，也十分地便于跨公司和跨业务做迁移，但是同时也是有很多现成的架构和 best practice 来让我们 leverage 。而另外的一方面，如何让系统满足业务（持续变动的）需求，则是一个看起来 less technical，却也找不到太多 best practice 的地方。一个值得参考的似乎是 DDD。
如果从成本的角度来考虑的话，做架构设计更像是固定成本而做功能设计则更像是非固定成本。因为如果假设一个系统做好以后，业务方随着迭代商业模型会不停地加功能上来，那么对于每次迭代来说，架构设计只（主要）在第一次构建系统的时候需要，而功能的设计则是需要在每次迭代都要有的。要是打个比方的话，想象一下你在经营一家饭店，那么你只需要在开店之前装修一次并且每一年固定付一次房租即可，这部分成本不以店内的客流量变化；但是同时每天有客人来到店里，你都要去购买食材，如果来得多你可以多进些，反之亦然。这就是固定成本和非固定成本的区别。这部分映射回系统设计，则是对应架构设计和功能设计。架构设计本身就是固定成本，同时功能设计本身则是非固定成本。但是架构设计的目标是减少固定成本和非固定成本；而功能设计则主要是减少非固定成本。
这个地方的成本主要指的是人力资源的成本，而不是服务器。服务器成本也很重要但是跟人力成本比较的话并不是一个数量级的。人力资源的成本则是指“实现这个（业务）功能需要多少人天”。
刚才说到了成本，那么下一个问题就是这部分成本是谁来承担的。这个就涉及到一个不可能三角的问题，“scope，resource 和 timeline”。这个我们以后有机会细说，简单来说就是业务方和开发共同承担。按照经济学的话来说，就是弹性越大承担越少。
当然这两者并不是一个完全非此即彼的分类。一些设计其实是要综合考虑两者的，比如如何设计一个分库分表的系统，如何确定 KV 存储的主键。这里主要着重于如何来设计功能来做到可复用和可扩展。至于架构思考上我的一些思考，之后会提到。
