架构是共识确认的过程
对于架构这一领域，存在一些常见的误解。作为架构师，需要掌握三个关键技能：理解需求的能力、读懂代码的能力和抽象系统的能力。
其中，“读懂代码”可能看起来没有明显的产出，但实际上也是必不可少的。不读懂代码意味着可能缺乏架构设计文档，因此有必要补充文档以提高理解。
理解需求的能力是架构师中最容易被忽视的一环，然而它却至关重要。很多架构师不知道如何进行需求分析，也不清楚需求分析的最终产出应该是什么样的。需求分析是架构设计过程中至关重要的一步，需要以实训的方式来加强理解。
抽象系统的能力也同样重要。许多架构师喜欢绘制架构图，但绘制完架构图后就认为架构工作完成了，接下来便是编码。然而，架构过程实际上是一个团队共识形成与确认的过程。而架构图往往并不精确，这可能导致团队缺乏精确的共识，进而影响模块间的工作协调。
更为精确的做法是定义每个模块的接口，并用代码来表达这些接口。代码是一种精确且无歧义的表达方式，能够帮助确保系统的一致性。因此，在概要设计阶段就编写框架代码，并通过代码来串联用户故事，是更为有效的方法。这样一来，我们就能在前期阶段就管理好工程的最大风险，剩下的工作便是每个模块自身的表现，而这取决于招聘的工程师个体素质。
因此，模块的接口是架构设计的核心。
别让框架绑架业务
接口代表着业务需求，是业务的具体表现。而架构图则代表着技术框架，是我们用来实现需求的工具。尽管框架在架构设计中扮演着重要角色，但也需要注意不让技术方案主导业务需求。在架构设计的两侧，一边是用户需求，一边是技术实现。
框架是技术的体现，它是满足需求的手段。然而，不应该让技术方案牵制住业务发展的方向。在系统迭代的过程中，技术框架可能会发生变化，以适应需求的演进。然而，稳定的需求背景是系统稳定性的关键。框架的设计需要具备对需求泛化的能力，通过抽象出需求模板，将多个需求场景中的变化部分抽离出来，形成相对稳定的泛化需求。
框架的抽象能力是逐步发展的，它不仅依赖于我们对系统的抽象能力，也依赖于对领域需求的深刻理解。如果框架不能满足需求，却不对其进行迭代，而是强行添加功能需求，可能导致代码逃离框架，破坏系统的整体结构。
在系统开发过程中，连接性的代码应尽量减少。连接性的代码指的是将两个独立的业务系统连接起来，形成一个大的业务场景。若出现大型业务场景，应该将其抽象为新的更大范畴的业务系统。这样能够保持焦点始终在业务层面上，有助于持续保持系统的清晰性。
在接口设计中，有一种趋势是使用框架来替代业务，甚至使用实现机制替代业务逻辑。我常对架构师们说：“比框架（架构图）更重要的是数据结构，比数据结构更重要的是接口。”为什么数据结构比框架更重要？因为业务数据结构是架构实现机制的灵魂。从共识确认的角度来看，数据结构相比框架而言更是重要的共识。
有些架构师可能清晰地思考了实现机制，但对业务理解却模糊不清。他们往往用实现机制来替代对业务系统的抽象。其中一个常见的情况是定义了数据结构，但却没有将业务逻辑进行抽象，直接让使用方操作成员变量，或者定义一堆成员变量的 get/set 接口。
另一个例子是在使用 ORM 框架操作数据库时，工程师容易犯的错误是直接操作数据结构，而忽略了定义业务接口的重要性。在这种情况下，业务逻辑没有被良好地抽象出来，使得整个系统变得难以理解和维护。因此，即使在使用框架的情况下，业务接口的定义仍然至关重要，它有助于提高代码的可读性、可维护性，确保业务逻辑清晰可见。
架构即是业务的正交分解。每个模块都承载着自己的业务功能。这里所说的模块是一个广义的概念，包括函数、类、接口、包、子系统、网络服务程序、桌面程序等等。尽管这个概念看起来很简单，但它却是至关重要的，以至于需要单独的讨论来深入理解。它是所有架构行为的基础。
架构行为通常分为三个步骤：需求分析、概要设计和模块的详细设计。这些步骤的核心目标都是业务的正交分解，只是在逐步递进的过程中，从模糊到越来越强的确定性，直至最终形成业务设计的完整、精确且无歧义的解决方案。