# **架构设计**

软件架构设计是一个过程，其中系统被分解为更小的部分（称为组件或模块），并确定这些部分如何交互和协作以完成系统的目标（这些组件可能是数据库、用户界面、服务器端逻辑等）。软件架构设计还涉及到决定如何将系统的各个部分组织到一起，以便满足性能、安全性、可维护性等非功能性需求。

**架构并不是软件**，关于软件设计的策略，是关于整体结构和组件的**抽象描述**。其目的是为了解决软件系统的复杂度可能带来的问题，用最小的成本来满足构建和维护系统的需求。



## 架构设计坑点

1. **需求未明确**：只关注功能性需求，忽略非功能性需求；

2. **过度设计**：具体的很多微观（详细）设计，架构设计文档信息过度，不适合未来需求变更和迭代；

3. **追寻大公司方案**：许多团队会看到大公司如Google或Facebook的架构方案，然后试图在自己的项目中实施相同的方案。这可能会忽视自己团队的技术能力、运维能力，以及业务体量（如是否真的需要处理高并发、高可用性的需求）。选择经济适用的方案，快速试错，根据团队能力和资源进行合理投入会更好。对于云平台等解决方案，可以考虑低配版本，以降低成本和复杂性。

4. **技术方案，喜新厌旧**：有些团队过于追求新技术，侧重技术，忽视了其他重要的因素：现有技术的优势和适用性、团队的协作能力、沟通能力和业务理解能力。在选择新技术时，应考虑其近期和远期的优势，对业务效率的影响，以及可能产生的技术债务。同时，也要考虑成本投入和效益产出，确保新技术的投入能够带来足够的回报。为了实现全面发展，需要平衡技术实力和软实力。

   > 与喜新厌旧对立面：**冷门技术**，但是不太适用一些热门场景，比如AI相关，因为本身资料就比较少，但是这个热门方向，随着技术的发屏会后续进行完善。

5. **脱离实践**：

   理论是来源于实践的，纸上谈兵往往无法达到预期效果。例如，微内核架构、响应式的服务架构、应用内分层等理论，都需要在实践中进行验证和调整。

   其次，需要考虑如何落地。这包括制定短中长期的规划，梳理上下游业务依赖，确定团队配置和招聘计划，以及定义业务目标和验收标准。同时，也需要制定上线后的业务开展计划。

   最后，需要有深入的专业知识，而不仅仅是广泛的知识。对于每个技术或工具，都需要知道它解决了什么问题，以及其优缺点和替代方案。



## 架构类型

从质量角度，理解架构的设计考虑因素，用最小的资源满足业务需求。

架构设计是确定系统的高层结构，并解决系统组件如何交互的过程。架构设计包括以下几个关键元素：

- **系统架构**：确定系统的总体结构，包括软件组件，硬件组件，网络，数据存储等。
- **软件架构**：设计软件的高层结构，包括确定软件的主要组件，以及这些组件如何交互。这可能涉及使用设计模式，如MVC，微服务架构等。
- **数据架构**：确定如何存储，处理，访问和保护数据。这可能涉及设计数据库模式，数据流程图，或数据管理策略。
- **网络架构**：设计系统中的通信网络，包括确定网络设备，协议，路由策略等。
- **安全架构**：确定如何保护系统和数据。这可能涉及制定安全策略，以及使用加密，身份验证，授权等技术。

> 架构类型还有很多，不局限于上面列举的。



## 设计模式

软件架构设计模式是常见的可复用的解决方案，用于处理在构建软件系统时经常遇到的设计问题。这些模式并非是能直接转换为代码或系统的设计，而是提供了一种在特定上下文中解决问题的模板。以下是一些常见的软件架构设计模式，以及它们的分类和简单说明：

1. **层次型架构模式**：这类模式强调如何将各个部分分解为可独立管理和理解的层。
   - **三层架构**：这种模式将应用程序分为三个主要部分：表示层（用户界面）、业务逻辑层和数据访问层。每一层都有特定的职责，可以独立开发和测试。
   - **N层架构**：这是三层架构的扩展，可以根据需要增加额外的层。例如，一个复杂的企业级应用可能包括用户界面层、应用层、业务逻辑层、数据访问层以及数据库层。
2. **数据流型架构模式**：这类模式主要关注数据的流动和变化。
   - **管道和过滤器模式**：这种模式允许数据经过一系列的处理阶段，每个阶段都是一个过滤器，可以进行一些操作（例如，转换、过滤或排序），然后将结果传递给下一个阶段。
3. **模块型架构模式**：这类模式强调如何将系统分解为可独立开发的模块。
   - **微服务架构**：这种模式将一个应用程序分解为一组小的、独立的服务，每个服务都运行在其自己的进程中，服务之间通过一种轻量级的通信机制（如HTTP REST、消息队列等）进行交互。
4. **事件驱动型架构模式**：这类模式关注如何在系统的各个部分之间传递事件或消息。
   - **发布/订阅模式**：在这种模式中，一个或多个组件（发布者）会产生事件，然后将这些事件发布出去。其他组件（订阅者）可以订阅这些事件，当事件发生时，订阅者会收到通知。
   - **观察者模式**：这是发布/订阅模式的一种变体，其中一个对象（主题）维护一系列依赖于它的对象（观察者），当主题的状态发生改变时，所有的观察者都会被通知。
5. **分布式系统架构模式**：这类模式解决分布式系统中的问题，如数据一致性、服务发现等。
   - **主-从架构模式**：在这个模式中，一个主服务器执行所有的读写操作，并同步数据到一个或多个从服务器。从服务器只能进行读操作。
   - **分布式数据模式**：在这个模式中，数据被分布在多个节点上，每个节点负责一部分数据。这种方式可以提高数据的可用性和处理能力。
   - **服务定位模式**：这是一个允许服务消费者和服务提供者在运行时发现彼此的设计模式。服务定位模式通常包含一个服务注册表，服务提供者在其中注册其可用性，服务消费者通过查询注册表找到所需的服务。
6. **用户界面设计模式**：这类模式解决用户界面的设计问题。
   - **模型-视图-控制器 (MVC)**：这是一种设计模式，用于将应用程序的数据、用户界面和用户输入分开。模型代表应用程序的数据，视图是用户看到的界面，控制器处理用户的输入。
   - **模型-视图-视图模型 (MVVM)**：这是一种用于将用户界面的逻辑和业务逻辑分开的设计模式。在此模式中，模型表示应用程序的数据，视图表示用户界面，视图模型是一个抽象，它包含视图所需的状态和行为。

> 这些只是一些常见的软件架构模式，实际上，还有许多其他的模式，可以根据特定的需求和上下文来选择和应用。



## 架构设计考量维度

1. **扩展性架构**：这个维度考虑的是系统在面临不断增长的用户数、数据量或事务处理时，是否能有效地增加系统的处理能力。

   扩展性可以在水平方向（增加更多的服务器）或者垂直方向（增强单个服务器的处理能力）进行。

2. **高性能架构**：这个维度主要关注的是系统的响应速度和处理能力。

   这通常涉及到算法的选择、数据结构的设计、并发处理、缓存策略等方面。

   何为高并发？

   "高并发"通常是指系统能够在同一时间处理大量并发请求的能力。在互联网服务中，高并发是非常重要的需求，因为可能会有大量用户在同一时间使用服务，如电商的双十一购物狂欢节、票务系统的抢票高峰期等。

   关于如何衡量一个系统的并发能力，有多种评价标准，如：

   - **吞吐量**：这是指系统在单位时间内处理的请求数量，通常用每秒请求数（Requests Per Second, RPS）或每秒事务数（Transactions Per Second, TPS）来表示，对于流业务来说（1GB/s=8Gbps）。

   - **响应时间**：这是指系统从接收到请求到发送出响应的时间。对于用户来说，更关注的可能是最大响应时间或者平均响应时间。

   - **并发用户数**：这是指系统能同时服务的用户数。这个数字可以反映系统的并发处理能力。

   - **系统资源使用率**：这包括CPU使用率、内存使用率、网络带宽使用率等，可以用来衡量系统在高并发条件下的性能。

3. **高可用架构**：这个维度要求系统必须在各种失败情况下仍能正常运行，以提供持续的服务。

   这通常需要通过冗余设计、故障切换、负载均衡等手段来实现。

4. **高安全架构**：这个维度强调的是保护系统和数据免受未经授权的访问和攻击。

   这涉及到用户认证、数据加密、防火墙设置、权限控制等安全措施。

5. **伸缩性架构**：伸缩性通常指的是系统在负载变化时，能自动地增加或减少资源的能力。

   在云计算环境中，这通常通过自动扩展和缩减服务器数量来实现。



## 架构设计工具

常见的架构设计的工具：

1. UML工具：
   - Visual Paradigm：这是一款提供中文界面的UML工具，支持UML、SysML、ERD等多种建模语言，提供多种模型模板和示例，适用于敏捷开发和DevOps环境；
   - StarUML：一款轻量级的UML工具，具有清晰直观的界面，支持各种UML图，支持自动布局，还有插件系统，可以扩展功能。该软件提供了中文版；
   - **Visio**：这是一款由微软开发的绘图软件，支持多种UML图（如序列图、状态图等）。它的特点是界面友好，操作简单，功能强大，适合初学者和专业人士；
   - Lucidchart：一款基于Web的UML工具，支持实时协作，可以在任何地方访问，不需要安装软件。也有丰富的模板和图形库。
2. 业务流程建模工具：
   - **ProcessOn**：一款基于Web的中文业务流程建模工具，不仅支持BPMN、UML等建模语言，还支持实时协作，有大量的模板和图库可以使用；
   - Bizagi Modeler：是一款专业的业务流程建模工具，支持BPMN（业务流程模型和符号）标准，可以很容易地创建和分享业务流程图；
   - **draw.io**（现在被称为 diagrams.net）是一款免费的、开源的在线绘图工具，用于创建各种类型的图表，包括流程图、序列图、ER图、UML图、网络图、业务流程模型图等。
3. 系统架构设计工具：
   - Archi：这是一款开源的企业架构工具，支持TOGAF和ArchiMate等企业架构框架。它具有良好的图形用户界面和强大的建模能力。
   - Sparx Enterprise Architect：这是一款全面的企业架构工具，支持UML、BPMN、SysML等多种模型标准。它提供了多种高级功能，如模型版本管理、模型仿真等。
4. 数据库设计工具：
   - **Navicat**：这是一款强大的数据库管理和设计工具，支持MySQL、PostgreSQL、SQLite等多种数据库，提供数据库设计、查询、数据迁移等功能，提供中文界面；
   - **PowerDesigner**：这是一款功能强大的数据库设计工具，支持多种数据库，提供物理、逻辑、概念三层建模，支持数据字典、版本控制等功能，有中文版本；
   - MySQL Workbench：这是一款MySQL数据库的设计工具，支持数据库的设计、开发和管理。它可以创建ER（实体关系）图，生成数据库表结构，执行SQL查询等；
   - ER/Studio：这是一款专业的数据建模工具，支持多种数据库系统。它可以帮助你创建高质量的数据库设计，管理数据库元数据，保证数据一致性。
5. 需求管理工具：这类工具主要用于收集、跟踪和管理项目需求。
   - JIRA：这是一款流行的项目和需求管理工具，被广泛用于敏捷开发。它可以帮助团队管理任务、故事、缺陷等需求，支持自定义工作流，有丰富的报告和图表。JIRA 提供中文版。
   - Teambition：这是一款国产的项目协作工具，提供任务管理、日程管理、文件分享、IM 聊天等功能。它也可以用于需求管理，支持创建和跟踪任务，标记优先级和进度。
   - 石墨文档（Shimo）：这是一个强大的在线协作文档工具，适用于写作、表格、幻灯片、表单等多种文档类型。可以进行实时编辑和评论，也可以设置文档权限，非常适合团队合作。
   - 飞书（Lark）：这是一款集成了文档、表格、邮件、日历和即时通讯的协作平台，可以帮助团队提高效率。飞书也提供了视频会议和云盘功能，支持与第三方应用集成。
   - 禅道（ZenTao）：这是一个项目管理软件，尤其适合软件开发团队。它支持敏捷开发，包含了产品管理、项目管理、质量管理、文档管理、组织管理和事务管理等功能。
6. 原型设计工具：这类工具主要用于创建软件或网站的用户界面原型。
   - Axure RP：这是一款功能强大的原型设计工具，支持创建丰富的动态交互和条件逻辑，可以生成高保真的原型。Axure 提供中文版。
   - 墨刀：这是一款来自国产的原型设计工具，简单易用，支持拖放操作，提供大量的组件和模板，可以快速创建原型。
   - 蓝湖：是一款优秀的设计协作平台，致力于提高设计效率。它可以帮助设计师创建互动原型，并与开发者、产品经理和其他团队成员共享设计和反馈。特点包括自动化标注，一键切图，版本管理，团队库等功能。



## 架构图绘制

软件架构图是一种视觉工具，用于描述系统的结构、关系和交互。架构图可以帮助开发人员、项目经理、利益相关者等理解系统的总体设计，以便于决策和协调。绘制架构图的方法和工具多种多样，一般来说，包括以下几个步骤：

1. 明确目标：确定绘制架构图的目的和受众。不同的受众可能对架构的关注点不同。例如，开发人员可能更关注技术细节，而项目经理可能更关注项目的进度和风险。
2. 选择视角：根据目标选择适当的视角。例如，可以从逻辑视角描述系统的功能模块和关系，从物理视角描述系统的硬件和网络布局，或者从开发视角描述代码的组织和依赖。
3. 收集信息：收集和整理需要在架构图中表示的信息，包括系统的组件、关系、约束等。
4. 绘制图形：使用绘图工具绘制架构图。常见的工具包括 Visio、draw.io、Lucidchart 等。在绘制过程中，应尽量使图形清晰、简洁，避免不必要的细节。
5. 评审和更新：定期评审架构图，并根据系统的变化和反馈进行更新。



以下是一些绘制架构图的注意点：

- 尽量保持图形的清晰和简洁，避免过度的细节。
- 使用标准的符号和颜色来表示不同的组件和关系。
- 在图形中包括重要的约束和决策，例如技术选择、性能需求等。
- 保持架构图的更新，以反映系统的实际状态。



## 架构验证

架构设计的验证是一个关键的步骤，它可以确保设计满足所有的功能和非功能需求，而且能够支持应用的长期发展。以下是一些常见的架构设计验证方法：

1. **架构评审**：架构评审是一种通过团队内部或外部专家对架构设计进行评估的过程。评审的目标是检查架构是否满足所有的业务和系统需求，是否具有良好的可扩展性，是否考虑了安全性和性能等关键因素。
2. **模拟和原型**：创建架构原型或模拟是一种有效的验证方法。这种方式可以帮助团队更好地理解架构的工作方式，同时也可以用来验证架构是否能够满足性能、可扩展性和其他非功能性需求。
3. **架构完整性检查**：这种方法主要是检查架构设计的完整性和一致性。例如，检查所有的组件和服务是否都有明确的职责，是否所有的接口和依赖关系都已经明确定义，以及是否所有的需求都已经被考虑和解决。
4. **使用架构决策记录（ADR）**：架构决策记录是一种记录架构设计和决策的方式，它可以帮助团队跟踪架构的变化，并确保所有的决策都有明确的理由和背景。通过审查ADR，团队可以验证架构决策是否合理，是否符合业务和系统需求。
5. **自动化测试**：自动化测试（包括单元测试、集成测试和系统测试）可以用来验证架构设计的有效性。这些测试可以检查系统的各个部分是否按照预期工作，以及整个系统是否能够满足性能和可靠性需求。



可以使用RAID架构验证工件来进行验证：

RAID 是 Risk, Assumption, Issue, and Dependency 的缩写，分别表示风险、假设、问题和依赖。

1. 风险（Risk）：指在架构设计和实施过程中可能出现的潜在问题或不确定性，可能会对系统的成功实施和性能产生负面影响。识别和评估这些风险可以帮助团队制定相应的风险缓解策略和计划。
2. 假设（Assumption）：指在架构设计和实施过程中基于推断或预设的前提条件。假设通常涉及系统环境、性能需求、技术可行性等方面。识别和记录假设可以确保架构设计和实施过程中的决策建立在合理的假设基础上。
3. 问题（Issue）：指在架构设计和实施过程中遇到的具体问题、障碍或挑战。问题可能涉及技术难题、资源限制、需求冲突等。跟踪和解决这些问题是保证系统成功交付的关键。
4. 依赖（Dependency）：指架构设计和实施中存在的依赖关系，包括依赖的外部系统、组件、数据等。识别和管理这些依赖可以帮助团队更好地规划、协调和整合系统的各个部分。



**关于ADR与RAID的区别：**

> 架构决策记录（ADR，Architecture Decision Record）和架构设计中的RAID（Risk, Assumption, Issue, and Dependency）是不同的概念，但它们在架构设计和管理中有一定的关联。

架构决策记录（ADR）是一种文档或工件，用于记录架构设计过程中做出的重要决策。

ADR旨在记录决策的动机、背景、选项和结果，以及它们对系统的影响。它提供了一个可追溯的记录，帮助团队理解和传达架构设计决策的原因和后果。

RAID（Risk, Assumption, Issue, and Dependency）是一种用于识别、记录和管理架构设计和实施过程中的风险、假设、问题和依赖关系的方法。RAID通常是一种框架或工具，用于跟踪和解决这些因素对系统开发和交付的潜在影响。

虽然ADR和RAID都用于记录和追踪架构设计过程中的相关信息，但它们关注的方面略有不同。

- ADR主要关注架构设计决策的记录，包括动机、选项、结果等，旨在提供对决策背后原因和思考过程的可追溯性。ADR对于记录架构决策的背景和理由非常有用，以及它们如何影响系统。
- RAID主要关注识别和管理架构设计和实施过程中的风险、假设、问题和依赖关系。RAID的目的是跟踪这些因素，以便团队能够及时采取措施来缓解风险、解决问题和管理依赖关系。

可以说，ADR可以包含对RAID中的一些因素的记录，如架构决策可能涉及的风险、假设和依赖关系。因此，ADR和RAID在一定程度上可以相互关联，但它们的关注点和目的略有不同。



## 架构落地

将架构设计落地是一项关键任务，需要深思熟虑和适当的策略。以下是一些策略和步骤：

1. **制定清晰的计划**：在实施架构设计之前，需要制定一个详细的实施计划。这个计划应该包括各个阶段的目标、时间表，以及需要的资源。同时，计划还应该包括如何处理可能出现的问题和风险。
2. **增量和迭代实施**：尽量避免一次性大规模的变更，而是通过增量和迭代的方式逐步实施新的架构设计。这种方式可以降低风险，同时也能够更快地获得反馈，并根据反馈调整设计。
3. **培训和教育**：如果新的架构设计引入了新的技术或概念，可能需要提供培训和教育给团队成员。这不仅可以帮助团队成员更好地理解新的架构，也可以提高他们的技能和能力。
4. **持续的沟通和反馈**：架构设计的实施需要全团队的参与和合作。因此，需要保持开放和持续的沟通，确保所有的人都理解新的架构，同时也可以收集他们的反馈和建议。
5. **使用适当的工具和技术**：有许多工具和技术可以帮助实施架构设计，如版本控制系统（如Git）、持续集成/持续部署（CI/CD）工具，以及各种测试和监控工具。
6. **测量和评估**：需要制定一套度量标准和指标，用来评估新架构的效果和影响。这些指标可能包括性能、可靠性、可维护性等方面。



## 架构演进

架构演进是指在软件系统的设计和开发过程中，对系统架构进行演化和优化的过程。而拆迁者模式、绞杀者模式和修缮者模式是架构演进中常见的三种模式，它们分别指代了不同的架构演进策略。

1. 拆迁者模式（Breaker Pattern）：指当现有的系统出现问题或无法满足需求时，**采取彻底重构和重新设计的方式**进行架构演进。这种模式可能会导致短期内的系统不稳定和业务中断，但可以在长期内获得更好的效益和可维护性。
2. 绞杀者模式（Strangler Pattern）：指在现有的系统中**逐步引入新的架构和技术**，通过渐进式的迁移和替换，逐渐“扼杀”旧有的架构。这种模式可以在保持系统稳定性的同时，实现架构演进。
3. 修缮者模式（Mender Pattern）：指通过对现有的系统进行**小规模的修改和优化**，来修复问题和增强系统的可维护性和可扩展性。这种模式适用于系统已经比较稳定，但需要持续进行维护和优化的情况。

这三种模式都有其适用的场景和优劣势，具体的架构演进策略应根据具体的情况来选择和调整。



## 架构设计方法论

### ADMEMS方法论

ADMEMS（Architecture Design Method has been Extended to Method System）是一种常用于任务和项目管理的方法论，涵盖了完整的架构设计过程，包括"需求导入、架构导出"的三个阶段和一个环节。这"三个阶段"指的是预备架构阶段（PA阶段）、概念架构阶段（CA阶段）和精化架构阶段（RA阶段），"一个环节"是指非功能性目标的考虑。

- 在PA阶段，任务是全面理解需求，以把握需求的特性，然后确定架构设计的驱动力。在此阶段，ADMEMS矩阵是该方法的核心；

- 在CA阶段，必须考虑所有的需求，包括功能、质量和约束，ADMEMS方法有自己的概念架构设计步骤和实践；

- RA阶段的总体方法是五个视图，涵盖逻辑架构、物理架构、开发架构、运行架构和数据架构。

此外，ADMEMS方法为软件架构设计提供了一整套的文档模板，涉及文档介绍、架构描述、架构设计目标、架构设计原则、逻辑架构视图、开发架构视图、运行架构视图、物理架构视图、数据架构视图和关键质量属性设计。在架构设计实践中，架构师可以直接使用这个文档模板来设计架构并描述架构。

这种方法系统在软件架构设计领域得到了认可，被誉为是高级的方法系统。在讨论架构设计不同阶段的分析方法和设计技术时，该系统给出了相应的实用策略、实践和有用的设计案例。这种方法具有高度的实用性，不仅对一线架构师和希望成为软件架构师的人有好消息，而且在推动中国软件行业的软件架构研究方面也起到了作用。



### ABSD架构方法论

ABSD（Attribute-Based System Design）架构方法论与需求驱动边界划分相关，但它并不是专门用于需求驱动边界划分的方法论。

ABSD方法论是一种面向属性的系统设计方法，旨在通过明确系统的关键属性和质量属性需求来指导系统架构的设计。它强调将系统需求和架构决策相结合，以满足系统的关键需求和目标。

**ABSD（Architecture-Based Software Design）基于架构的软件设计方法** 有三个基础：

第一个基础是功能分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术。

第二个基础是通过选择架构风格来实现质量和业务需求。

第三个基础是软件模板的使用。软件模板利用了一些软件系统的结构。 

ABSD模型把整个软件过程划分为：架构需求、设计、文档化、复审、实现、演化。

1. **架构需求：**

   需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。架构需求受技术环境和架构设计师经验的影响。需求过程主要是获取用户需求，标识系统中所要用到的构件。如果以前有类似的系统架构的需求，我们可以从需求库中取出，加以利用和修改，以节省获取需求的时间，减少重复劳动，提高开发效率。

2. **架构设计：**

   架构需求用来激发和调整设计决策，不同的视图被用来表达与质量目标有关的信息。架构设计是一个迭代过程，如果要开发的系统能够从已有的系统中导出大部分，则可以使用已有系统的设计过程。

3. **架构文档化：**

   绝大多数的架构都是抽象的，由一些概念上的构件组成。例如，层的概念在任何程序设计语言中都不存在。因此，要让系统分析师和程序员去实现架构，还必须得把架构进行文档化。文档是在系统演化的每一个阶段，系统设计和开发人员的通讯媒介，是为验证架构设计和提炼或修改这些设计（必要时）所执行预先分析的基础。架构文档化过程的主要输出结构是架构需求规格说明和和测试架构需求的质量设计说明书这两个文档。生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。软件架构的文档要求与软件开发项目中的其他文档是类似的。文档的完整性和质量是软件架构成功的关键因素，软件架构文档应该从使用者的角度进行书写，针对不同背景的人员采用不同的书写方式，并将文档分发给相关人员。架构文档要保持较新，但不要随时保证文档最新，要保持文档的稳定性。

4. **架构复审：**

   架构设计、文档化和复审是一个迭代过程。从这个方面来说，在一个主版本的软件架构分析之后，要安排一次由外部人员（用户代表和领域专家）参加的复审。复审的目的是标识潜在的风险，及早发现架构设计中的缺陷和错误，包括架构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求等。由外部人员进行复审的目的是保证架构的设计能够公正地进行检验，使组织的管理者能够决定正式实现架构。

5. **架构实现：**

   所谓实现就是要用实体来显示出一个软件架构，即要符合架构所描述的结构性设计决策，分割成规定的构件，按规定方式互相交互。

6. **架构演化：**

   在构件开发过程中，最终用户的需求可能还有变动。在软件开发完毕，正常运行后，由一个单位移植到另一个单位，需求也会发生变化。在这两种情况下，就必须相应地修改软件架构，以适应新的变化了的软件需求。

需求驱动边界划分是一种与ABSD方法论相关的技术或方法，它强调根据系统需求的边界和上下文来划分系统的模块、组件或微服务。这种划分基于系统的功能需求、上下文边界和业务边界，以实现模块化、可扩展和可维护的系统设计。

虽然ABSD方法论可以帮助识别和明确系统的关键属性需求，但它并不专门关注边界划分的技术或方法。需求驱动边界划分可以与ABSD方法论结合使用，以在系统设计中同时考虑需求和边界划分的问题。



### DSSA方法论

DSSA（Domain-Driven System Architecture）是一种基于领域驱动设计（Domain-Driven Design，DDD）的架构方法论。领域驱动设计是一种软件开发方法，旨在解决复杂业务领域中的设计和开发挑战，通过将业务领域的知识和理解融入到软件系统的设计和实现中。

DSSA方法论的**核心思想是将领域驱动设计的原则和概念应用于整个系统架构的设计过程**。它强调将业务领域作为系统设计的核心，将业务需求和业务逻辑作为架构设计的驱动因素。

DSSA方法论提供了一些指导原则和实践，用于将领域模型（Domain Model）贯穿于整个系统架构的各个层次和组件之间。这包括将业务概念映射到领域模型、定义领域服务和聚合根、使用界限上下文（Bounded Context）进行上下文边界划分等。

通过DSSA方法论，架构师可以更好地理解和应用领域驱动设计的原则，将业务领域的复杂性分解为可管理的领域模型，实现系统架构的灵活性、可维护性和可扩展性。这种方法将业务专家和开发团队之间的沟通桥梁加强，有助于实现业务需求和软件系统之间的紧密衔接。



用于将领域驱动设计的原则应用于系统架构的设计过程：

1. 理解业务领域：深入了解业务领域，与业务专家合作，探索业务的核心概念、业务规则和业务流程。这包括对业务需求、目标和约束的全面理解。
2. 定义领域上下文：将业务领域划分为不同的上下文，每个上下文都有自己的业务边界和上下文限界。确定上下文之间的关系和交互方式，以及上下文边界的清晰定义。
3. 构建领域模型：根据业务领域的理解和上下文边界的划分，构建领域模型。领域模型是对业务领域中的概念、关系和规则的抽象表示。通过使用领域模型，将业务领域的知识融入到系统架构中。
4. 设计领域服务：基于领域模型和业务需求，设计和定义领域服务。领域服务是一些提供特定业务功能的服务，通过操作领域模型来实现业务逻辑。这些服务负责管理领域对象的状态和行为。
5. 定义聚合根：识别和定义聚合根（Aggregate Root），它是领域模型中的核心实体，具有聚合边界和一致性边界。聚合根负责保护和维护聚合内的业务规则和完整性。
6. 确定架构模式和技术：根据业务需求、领域模型和系统规模，选择适当的架构模式和技术。这可能包括事件驱动架构、微服务架构、CQRS（Command Query Responsibility Segregation）、事件溯源等。
7. 实施和迭代：在设计和实施系统架构时，与开发团队合作，根据反馈和实际情况进行迭代。根据实际业务需求的变化和演化，逐步调整和改进系统架构。



## 一些名词

### 上下文

在架构设计中，上下文（Context）指的是系统、组件或模块所处的环境和相关因素，以及与其交互的实体或系统。它包含了对系统进行设计的背景、目标和约束条件的理解。

上下文对架构设计非常重要，因为它提供了设计决策的基础和指导。通过理解系统的上下文，架构师能够更好地评估系统的需求、挑战和机遇，从而做出相应的设计选择。

上下文可以包括以下内容：

1. 功能需求：理解系统所需实现的功能和业务流程。这包括了系统与其他系统或组件的接口和交互，以及系统在不同使用场景下的行为和响应。
2. 非功能需求：考虑系统所需满足的非功能性要求，如性能、可伸缩性、可靠性、安全性、可维护性等。这些要求通常来自业务需求、用户期望或行业标准。
3. 技术约束：了解系统开发和部署所面临的技术限制和约束。这可能包括硬件平台、操作系统、开发语言、框架和库的选择，以及组织内部的技术栈和技术能力。
4. 组织和团队：考虑组织的组织结构、团队能力和合作方式。这涉及到架构设计的可实施性、可维护性和可持续性，以及设计与组织战略和目标的一致性。
5. 外部因素：了解系统所处的外部环境和因素，如法规、政策、市场竞争、用户期望和趋势等。这些因素可能对系统的设计和演化产生重要影响。

通过全面理解系统的上下文，架构师可以更好地把握系统的需求和约束，从而做出适当的设计决策。这有助于确保系统在满足功能和非功能需求的同时，与外部环境和组织策略保持一致，并为未来的需求变化和演化提供扩展性和灵活性。



### RASCI决策矩阵

RASCI决策矩阵是一种常用于确定和定义组织中各个角色在项目、流程、任务等中所扮演的角色和职责的工具。它可以帮助组织中的成员清晰地了解他们在不同的工作中所承担的职责和责任，并且协调不同角色之间的工作。

RASCI是由Responsibility、Accountability、Support、Consulted和Informed这五个单词首字母缩写组成的，每个字母表示不同的角色和职责：

- Responsibility（责任）：指实际执行某项任务或工作的人员，负责完成具体的工作内容；
- Accountability（账户责任）：指需要对某项任务或工作的结果进行负责的人员，通常是负责制定决策并确保其执行的高层管理人员；
- Support（支持）：指为完成任务或工作提供支持和资源的人员或部门，他们可能提供必要的知识、技能或资源；
- Consulted（咨询）：指在决策过程中需要征求意见和建议的人员或部门，他们可能提供有关任务或工作的信息、建议和专业知识；
- Informed（知情）：指需要了解任务或工作进展情况和结果的人员，他们可能需要及时获取有关信息以支持其工作。

在RASCI决策矩阵中，针对每个任务或工作，可以使用这五个字母中的一个或多个来定义不同角色的职责和责任。通过使用RASCI矩阵，可以帮助组织中的成员更好地理解和管理他们的角色和职责，以及促进更有效的协作和决策。



### ADMEMS矩阵

![ADMEMS矩阵-需求层次-需求方面矩阵](https://static.www.toimc.com/blog/picgo/2023/06/03/ADMEMS%E7%9F%A9%E9%98%B5-%E9%9C%80%E6%B1%82%E5%B1%82%E6%AC%A1-%E9%9C%80%E6%B1%82%E6%96%B9%E9%9D%A2%E7%9F%A9%E9%98%B5-3113d2.webp)

ADMEMS矩阵是一种进行需求结构化的工具，参考[链接](https://tonydeng.github.io/architect-manual/ch4/4.2.html#422-%E5%B7%A5%E5%85%B7%EF%BC%9Aadmems%E7%9F%A9%E9%98%B5)。