不想做架构师的 Gopher 不是好程序员

最近我们在组队学习《手把手带你写一个web框架》，强制 PUSH，坚持每天学习打卡，不完成惩罚发红包的那种。

你别说，效果还真挺好。

昨天学到了架构部分，很受启发，光学不写假把式。（还是得坚持输出哇）

我站在大佬的肩膀上输出一篇总结文章出来，希望对大家有帮助：

概述

所谓架构，与一线开发最大的不同就在于是否有系统设计工作。架构师的价值已经不再体现在编码实现上，而更多地体现在设计上。

本文将重点介绍业务架构师和基础架构师的工作内容和职责，以及在架构设计中的重要性和作用。

业务架构师和基础架构师的职责

基础架构师主要负责基础服务的架构设计，这些服务是和业务无关的，包括数据库、缓存、队列等几乎所有业务都会使用到的服务。而业务架构师则主要负责让技术更好地服务业务。

在架构设计中，实现一个功能的方法有很多种，但是最符合自身业务的技术选型才是最优的。因此，业务架构师必须了解业务特点和需求，从而做出最优的技术决策。而基础架构师则需要深入了解基础服务的特点和性能，以及如何为业务提供最优的基础架构支持。

合作与沟通

对于技术人员而言，最终的技术能力模型应该是一个大 T 字形，即在某个领域有足够的深度，在多个领域有足够的广度。因此，虽然基础架构师和业务架构师具有不同的技术背景和专业领域，但两者之间的交流和合作至关重要。只有通过合作，才能确保系统的整体性和稳定性。

不管你的能力有多强，接手新的业务时，前三个月尽量不要做大的架构级别的修改，因为不熟悉业务，没有足够时间了解一线的代码逻辑，是不可能做出好的架构调整的。

架构设计中的原则和规律

基础架构的同学更大可能是往技术专家方向发展。他们对技术的成就感更多来源于为某个软件或某种语言增加特性，比如会追求成为 Apache PMC、微软的 MVP 等。他们的研究有可能改变某个技术行业。如果想走这个方向，必须热衷于某个技术行业。

《系统架构 - 复杂系统的产品设计与开发》这本书告诉读者如何做出一套思考系统架构的方式，即一些思考系统的原则和定律。整理一下对我有启发的原则：

1. 歧义原则：系统架构的早期阶段充满了歧义。架构师必须解决这种歧义，以便给架构团队定出目标并持续更新该目标。

2. 架构师角色原则：架构师的角色是解决歧义，专注创新，并简化复杂度。

3. 架构决策原则：要把架构决策和其他决策分开，并且要提前花一些时间来谨慎地决定这些问题，因为以后如果要想变更会付出很大的代价。

4. Conway 定律：设计系统的组织，总是会产生出与该组织的沟通结构相同的设计。

5. 产品进化原则：系统必须进化，否则就会失去竞争力。因此，在架构设计中，必须考虑系统的可扩展性和可维护性，以适应未来业务的变化和发展。

6. 2 下 1 上原则：要想判断对 level1 所做的分解是否合适，必须再向下分解一层，以确定 level2 中的各种关系。

这些原则和规律对于架构师的工作非常有帮助，可以帮助他们更好地理解系统架构，做出更优秀的设计。

结论

总之，业务架构和基础架构在架构设计中扮演着不同的角色和职责，但两者之间的合作是非常必要的。

架构师必须具备足够的技术深度和广度，以及良好的沟通和合作能力，才能为企业构建稳健和可靠的系统架构。