最近咱们在组队学习《手把手带你写一个 web 框架》，强制 PUSH，保持每天学习打卡，不实现惩办发红包的那种。
你别说，成果还真挺好。
昨天学到了架构局部，很受启发，光学不写假把式。（还是得保持输入哇）
我站在大佬的肩膀上输入一篇总结文章进去，心愿对大家有帮忙：
概述
所谓架构，与一线开发最大的不同就在于是否有零碎设计工作。架构师的价值曾经不再体现在编码实现上，而更多地体现在设计上。
本文将重点介绍业务架构师和根底架构师的工作内容和职责，以及在架构设计中的重要性和作用。
业务架构师和根底架构师的职责
根底架构师次要负责根底服务的架构设计，这些服务是和业务无关的，包含数据库、缓存、队列等简直所有业务都会应用到的服务。而业务架构师则次要负责让技术更好地服务业务。
在架构设计中，实现一个性能的办法有很多种，然而 最合乎本身业务的技术选型才是最优的。因而，业务架构师必须理解业务特点和需要，从而做出最优的技术决策。而根底架构师则须要深刻理解根底服务的特点和性能，以及如何为业务提供最优的基础架构反对。
单干与沟通
对于技术人员而言，最终的技术能力模型应该是一个大 T 字形，即在某个畛域有足够的深度，在多个畛域有足够的广度。因而，尽管根底架构师和业务架构师具备不同的技术背景和业余畛域，但两者之间的交换和单干至关重要。只有通过单干，能力确保零碎的整体性和稳定性。
不论你的能力有多强，接手新的业务时，前三个月尽量不要做大的架构级别的批改，因为不熟悉业务，没有足够工夫理解一线的代码逻辑，是不可能做出好的架构调整的。
架构设计中的准则和法则
基础架构的同学更大可能是往技术专家方向倒退。他们对技术的成就感更多来源于为某个软件或某种语言减少个性，比方会谋求成为 Apache PMC、微软的 MVP 等。他们的钻研有可能扭转某个技术行业。如果想走这个方向，必须热衷于某个技术行业。
《零碎架构 – 简单零碎的产品设计与开发》这本书通知读者如何做出一套思考零碎架构的形式，即一些思考零碎的准则和定律。整顿一下对我有启发的准则：
- 歧义准则：零碎架构的晚期阶段充斥了歧义。架构师必须解决这种歧义，以便给架构团队定出指标并继续更新该指标。
- 架构师角色准则：架构师的角色是解决歧义，专一翻新，并简化复杂度。
- 架构决策准则：要把架构决策和其余决策离开，并且要提前花一些工夫来审慎地决定这些问题，因为当前如果要想变更会付出很大的代价。
- Conway 定律：设计零碎的组织，总是会产生出与该组织的沟通构造雷同的设计。
- 产品进化准则：零碎必须进化，否则就会失去竞争力。因而，在架构设计中，必须思考零碎的可扩展性和可维护性，以适应将来业务的变动和倒退。
- 2 下 1 上准则：要想判断对 level1 所做的合成是否适合，必须再向下合成一层，以确定 level2 中的各种关系。
这些准则和法则对于架构师的工作十分有帮忙，能够帮忙他们更好地了解零碎架构，做出更优良的设计。
论断
总之，业务架构和基础架构在架构设计中扮演着不同的角色和职责，但两者之间的单干是十分必要的。
架构师必须具备足够的技术深度和广度，以及良好的沟通和单干能力，能力为企业构建持重和牢靠的零碎架构。