软件架构 - 概述

什么是软件架构

关于软件架构，似乎目前还没有一个标准的定义，我理解本质上架构仍然属于设计的范畴，不过是更为宏观的层面上对我们所要满足的需求或解决的问题的抽象设计，对更细节的设计和实现起到指导或约束作用。狭义上来说软件架构是指对我们需要构建的软件的结构设计，广义上我认为还会包含安全架构、数据架构、部署架构等不同的角度对我们所要构建的软件的设计。

没有银弹

没有普适性的解决方案，我认为这也是架构最吸引人的地方，这代表这是一样创造性的工作。因此我们需要尽可能地了解不同的架构方法，包括其优点、不足以及其解决的特定问题。

由于技术的不断进步发展，我认为这需要终身学习

最终，在我们面对具体的场景时，需要先理解清楚业务场景和用户的需求，然后思考应该使用什么样的架构（通常是多种架构的组合），它们既可能是一种已知的解决方案，也可能是我们创造出的适合特定场景的独特设计。

架构师

负责主要的架构设计工作和架构决策的人。我认为他们因该都是由开发者成长而成，他们应该是团队中经验最丰富的开发者之一，而要避免生活在象牙塔里的架构师（缺少实际的开发经验）。同时，反过来，我认为所有具有一定经验的开发者在某种程度上来说都是架构师，因为他们都要了解架构，参与到架构设计的讨论，并同时在具体的设计和实现上需要承担维护架构的职责。

软件架构历史

• 1970s

MVC 模式

• 1980s

HMVC 模式

LSP

分层架构

• 1990s

Message Bus

EBI 架构

SOA 架构

MVP 模式

OCP, ISP, DIP, REP, CRP, CCP, ADP

SDP, SAP

ESB

• 2000s

SRP

属性驱动设计

领域驱动设计

MVVM

六边形架构

CQRS、Event Sourcing

洋葱架构

微服务架构

SEDA

• 2010s

DCI 架构

clean 架构

C4 模型

Service Mesh

Explicit 架构

架构的坏味道

我们的世界是变化的，因此我认为架构的主要目的之一是为了应对变化。坏味道也是在应对变化时产生的，否则就是现有的错误，而不是坏味道了。

• 难以理解

结构混乱难以理解，需要仔细阅读和思考实现的细节去理解代码的行为。

• 难以修改

模块或代码之间关联复杂，牵一发而动全身。

• 重复

需要在多处进行相同或类似的修改（主要指业务逻辑或规则的处理）。

• 修改的影响未知

修改后的代码造成难以预料的影响。

• 难以测试或验证

软件的模块或代码难以进行独立的测试或验证。

• 过于复杂

过度设计，使结构过于复杂。未来的变化无法全部预知，因此重要的在于易于修改，而不是预知变化。