awesome-architecture/tutorial/01-%E4%B8%BA%E4%BB%80%E4%B9%88%E5%85%88%E6%9C%89%E6%9E%B6%E6%9E%84%E6%80%9D%E7%BB%B4

[giscus[bot]]

awesome-architecture/tutorial/01-%E4%B8%BA%E4%BB%80%E4%B9%88%E5%85%88%E6%9C%89%E6%9E%B6%E6%9E%84%E6%80%9D%E7%BB%B4

专注「架构思维」的中英双语知识库:40 章教程 + 31 张真实系统架构地图 + 6 个端到端案例。

https://study8677.github.io/awesome-architecture/tutorial/01-%E4%B8%BA%E4%BB%80%E4%B9%88%E5%85%88%E6%9C%89%E6%9E%B6%E6%9E%84%E6%80%9D%E7%BB%B4

[kkkingoos]

A团队错了吗？再实际推进来看A没错，老板要的是效果，是起手快，响应快，要体现团队价值A是对的。而且业务发展到哪一步是未知，再开发节点中，未知其实际日活，就预估日活几十万，属于过度设计没法交差（PS：日活几十万的产品再全球都算顶尖产品了）
B团队对了吗？架构对了，但是业务起手慢了，团队无响应，业务无推进。关键再老板看来，这是你本该做好的事情，本该做好的事情却要再几个月后或者说要到日活几十万才看得出价值，那么技术对了，架构对了，最大的价值就是自我感动的情绪价值。

总体来说根据业务涉及合适的架构，所有开发都是业务先行

[study8677]

同意，业务优先；B 队也不是按几十万 DAU 过设计，只是把那些事后很难改的决定先想清楚。