架构中那些需要注意的事儿

架构的定义

架构这个词最早是跟随着建筑出现的，进入到软件行业后，它的含义有了一些变化，但最基础的含义还是没有变的。本质上来说，架构是一个设计动作和实现动作；设计动作描述的是勾勒出满足客户战略规划需求的产品；实现动作描述的是将构件组合成结构的过程。

架构的分类

依据架构的定义，可以将架构分类为产品架构和软件架构两个大类。

在这两个大类下，还可以继续划分子类，如下：

产品架构

• 业务架构

• 应用架构

• 解决方案架构

软件架构

• 数据架构

• 基础结构架构

• 特定技术架构

上面只是列出了一部分架构子分类，理论上还可以继续划分，但在大多数的实际生产中，通常不会有这么详细的分类，常态是软件架构与产品架构都由一个人负责实现。

架构的设计方法

软件架构有很多设计方法，每一种都有自己的核心思想；实际生产中，一个产品的生存周期中通常就只会贯彻一个设计方法。

基于设计方法搭建的框架，清晰度会更高。下面简单介绍一下ABSD软件设计方法。

ABSD（Architecture-Based Software Design）基于架构的软件设计方法

ABSD软件设计方法是递归的，且迭代的每一个步骤都是清晰地定义的。因此，不管设计是否完成，体系结构总是清晰的，这有助于降低体系结构设计的随意性。

• 架构

  在ABSD中，架构被分为三个基础元素，分解、风格、模板。

  分解：基于一定的原则对模块进行内聚和耦合技术。如：职者分离原则，通用专用原则，技能分离原则，工作量均衡原则。

  风格：通过选择架构风格来实现质量和业务需求。如数据流风格（TCP，UDP），调用返回风格（SOA，微服务），独立构件风格（事件驱动），虚拟机风格（集群），仓库风格（ERP）。

  模板：一个特殊类型的软件元素，它使用一些已有的软件系统的结构，描述所有这种类型的元素在共享服务和底层构造的基础上如何进行交互。

• 过程

  在ABSD中，软件过程划分为：架构需求、设计、文档化、复审、实现、演化；如下图：

1，需求：

需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。如果以前有类似的系统的需求，我们可以从中提取，加以利用和修改，以节省需求形成的时间，减少重复劳动，提高开发效率。

2，设计：

贯彻一种设计方法，对项目结构进行搭建，并且对关键功能进行一些决策（需求是决策的基础）。设计其实也是一个迭代过程，需要不停的进化，可以使用旧有的设计元素进行组合搭建，进而减少重复劳动。

3，文档化：

通常架构是抽象的，并且拥有大量约定与配置。所以，为了让程序员更好的理解架构，不去破坏框架，还必须得把架构进行文档化。架构文档要保持较新，但不要随时保证文档最新，要保持文档的稳定性。

4，复审：

架构设计、文档化和复审是一个迭代过程。是阶段性的总结，目的是发现潜在的风险，及架构设计中的缺陷和错误。从现实方面来说，我们很难在一个主版本的发布之后，安排一次外部人员，用户代表，领域专家集体参加的复审。所以通常复审需要有架构师主动在某一个阶段主动进行。

5，实现：

所谓实现就是构建出一个软件架构，即要符合设计（决策），也要便于程序员开发。

6，演化：

通常软件开发过程中都会有一些方向性的修改或大型需求功能变化。在这情况下，就必须相应地修改软件架构，以适应新的变化了的软件需求。

架构的实现

架构的实现有很多种方法，同样的方法，步骤也可以不同，所以，实现是多种多样的。

理想化的环境下，设计与实现是顺序进行的；但在实际生产中，设计与实现通常是同步进行，我们常见的架构顺序是这样的。

一，分解子系统和功能模块；

二，设计框架模型；

三，分析功能模块；

四，设计框架详细。

当然，在更糟糕的实际生产环境中，这四步也相互穿插，同步进行情况也是有的。

架构重点关注问题

架构一个项目时通常要思考三个W——Who：为谁设计？What：要解决用户的什么问题？Why：为什么要解决这些用户问题？

此外还要重点关注以下问题。

1. 理解系统要解决的问题。

2. 认识系统特性与要解决的问题间的关系。

3. 识别系统的核心行为。

4. 整理系统的非功能性需求。

5. 确定架构需求。

6. 管理需求。

7. 规划系统的高层组织。

8. 确定架构机制。

9. 分析用例场景。

10. 演进系统的高层组织并形成组件模型。

11. 规划系统的运行时架构和部署模型。

12. 规划系统的实现模型。

13. 编写核心代码。

14. 验证架构设计。

15. 整理架构文档。

16. 高内聚，低耦合。

结语

关于架构

架构是细节的集合，不是文档组合，不论文档编写的多么棒，没有代码细节，都不能称之为架构。

关于架构师

架构与架构师是不一样的，学满了架构知识，也不一定能成为架构师的；而不了解架构的内容，也不一定无法成为架构师。很多时候，架构师是与架构相反的存在，比如，文档高手往往是高级架构师。

----------------------------------------------------------------------------------------------------

注：此文章为原创，任何形式的转载都请联系作者获得授权并注明出处！
若您觉得这篇文章还不错，请点击下方的【推荐】，非常感谢！

https://www.cnblogs.com/kiba/p/14097006.html