技术架构与体系结构

存在即合理，存在有其合理的原因，改变存在之前先了解存在的合理原因，1929年，G.K.切斯特顿提出了一个现在被称为“切斯特顿栅栏（Chesterton's Fence）”法则：在某种情况下存在某种制度或法律，为了简单起见，我们可以把它当做道路上竖立一道栅栏或大门。后来的改革者会欢欣鼓

通常，当我们解决一个问题时，最终会无意间创造出另一个更糟的问题。检查我们的决策的长期后果的最佳方法是使用二阶思维。二阶思维不仅是

本文个人研究。有些内容可能并非100％准确，但我已尽力保持其准确性，信息量和价值。 1. Uber系统设计

敏捷的软件公司组织结构最好能映射到业务领的结构，公司组织结构不要映射到技术。DDD创建了一个从领域映射到软件技术的架构。如果有界上下文是商店、仓库和财务，那么架构中最大的可模块化部门就是商店、仓库和财务，而不是“前端”和“后端”之类技术的东西。康韦定律（Conway'

多租户应用程序部署体系结构可以通过4种广泛的方式建模：单独的应用程序和单独的数据库共享应用程序和共享数据库单独的应用程序和共享数据库共享应用程序和单独的数据库这里没有对与错。您应该考虑业务背景和约束条件

美国莫德纳公司CEO Bancel先生在一月份曾在瑞士参加一次商务会议，当时他听说中国武汉发生了致命的新病毒爆发。他立即联系了两位NIH疫苗专家，他的公司多年来一直与他们合作开发可用于设计疫苗的技术，这种即插即用的系统将彻底改变人类如何应对新病原体。如果该系统有效，那么将在几天内完成

最喜欢的（微服务）语录：“对于想要跨服务实现事务的架构师的最佳建议是：不要！” - 书籍《软件架构基础》

软件架构类似房子，这个房子代表一个递归式应用，由顺序、选择和迭代等组成，这个应用被放设计进入一个面向对象的结构中，类似房子设计成三室一厅两厨卫这样的结构，而穿越结构的说水管电线管，这些管线是由函数式编程控制的不变性数据组成。banq注：以DDD为例，聚合结构是一种面向对象设计方式，而

KISS（保持简单愚蠢）： 即使解决方案看起来很愚蠢，简单的解决方案也比复杂的解决方案好。 当解决方案使用较少的继承，较少的多态性，较少的类等时，解决方案会更好。 更简单的解决方案更易于维护，即检测和纠正缺陷更加有效。

大多数问题和改进的最大可能性都属于该系统。试图从整体上理解系统，并考虑系统元素之间的相互作用。在系统中，所有事物都与某物相连。没有什么是完全独立的。这些联系和互动以及目的是系统的特征。更正式地讲，系统可以描述为：“一组元素

Clean架构能够解决这些问题 :过早下决策难以改变以框架为中心以数据库为中心只注重技术层面难以找到想找的代码业务逻辑到处扩散过重过多的测试

微服务很难，构建可靠且可测试的微服务比大多数人认为的要难得多，有效地“测试”微服务需要大量的工具和远见。-许多（或大多数）公司组织都不需要Netflix / Uber风格的微服务。宏服务Macroservices？ -并非整体/单体monolith -有不超过

忘了开发人员吧，今天的王国创造者被称为架构师，而且研究继续表明，如果按照架构师的偏好会采用不同的技术。一个典型的例子是数据库。根据

对于那些经营企业的人来说，拥有一个企业结构或框架是有效，成功地完成它的基本需求。这是企业架构师专业人员的工作， 他们将利用他们的TOGAF培训和技能通过映射企业框架来帮助组织，从而使企业可以轻松运行。TOGAF指开放组架构框架，它是一种企业架构方法，可为企业软件开发提供高级框架。

架构模式是捕获经过验证的良好设计结构的方法，以便可以重复使用它们。软件架构师一直在寻找方法来捕获和重用过去证明是成功的架构知识。 更具体地说，架构模式是在实践中反复发现的设计决策包，具有定义明确的属性，可以重复使用并描述一类架构。 开发体系结构可以看作是选择，定制和组合模式的

解决面试问题101： 不要立即提出解决方案 提出问题以搞清楚需求 大声解释您做出的每个判断与决策 谈谈解决方案中的权衡 如果失败，请进行下一次面试 另外，如果失败，请找出原因，不要两次犯同样的错误