1. Introduction 引子

1.1. 软件架构是什么

• IEEE:是⼀个系统基本的组织，具体表现为它的组件，组件之间的关系、指导系统设计和演化的环境与准则
• SEI:软件架构是程序或者计算系统的结构（structure），包含软件元素，元素外部可⻅的属性以及元素之间的关系

1.2. 软件架构用来做什么

1. 将系统分解成组件、模块和子系统：定义了组件的接口，组件的交互和相互依赖关系，以及组件的职责
2. 说明了交流方式：包括数据传输机制和控制流
3. 架构处理非功能需求，包括技术约束、业务约束和质量属性

1.3. 软件架构师（Software Architect）的作用

1. 联络（liaison）：在客户、技术团队和商业、需求分析师之间，包含了管理层或营销层
2. 软件工程：软件工程的最佳实践
3. 技术知识：对技术领域的深度理解
4. 风险管理：与设计、技术选择有关的风险

1.4. 架构设计来自于哪里

1. NFRs
2. ASRs
3. 质量需求
4. 涉众，组织
5. 技术环境
6. 业务目标
7. 商业与技术决策组合

1.5. 架构视图（P.Krutchen的4+1视图模型）

1. 逻辑视图：描述了体系结构中在体系结构上明显重要的元素以及它们之间的关系
2. 过程视图：描述了体系结构中的并发和交流元素
3. 物理视图：描述了主要过程和部件是如何映射到应用硬件上的
4. 开发视图：描述了软件部件是如何在软件内部组织的，比如配置管理工具
5. 用例场景（Use Case）：捕获架构需求，与一个或多个特定视图相关

1.6. 软件体系结构活动（Architecture Activities）以及每一步输入输出

1. 创建系统的商业案例

1. 1. 输入：问题域， 输出：商业案例

1. 理解需求

1. 1. 输入：用户的模糊需求 输出：架构攸关的需求

1. 创建和选择体系结构

1. 1. 输入：策略、模式和备选场景 输出：被选中的策略、模式和场景

1. 沟通体系结构

1. 1. 输入：架构设计文档 输出：无

1. 分析或评估体系结构

1. 1. 输入：结构设计文档 输出：无

1. 实现体系结构

1. 1. 输入：架构设计文档 输出：架构设计的具体实现

1. 保证和体系结构的一致性

1. 1. 输入：架构设计的具体实现 输出：保持一致的架构设计具体实现

1.7. 软件体系结构过程（Architecture Process）

1. 识别ASRs

1. 1. 输入：涉众
   2. 输出：高优先级质量属性场景

1. 架构设计

1. 1. 输入：高优先级质量属性场景、需求和约束、模式和策略
   2. 输出：一组候选视图的草图（由模式决定）

1. 文档

1. 1. 输入：一组候选视图的草图（由模式决定）、涉众
   2. 输出：View & Beyond

1. 架构评估：选择、组合视图，将文档进行进一步的评估。

1. 1. 输入：View & Beyond、高优先级质量属性场景、涉众
   2. 输出：View & Beyond

2. Quality Attributes质量属性

2.1. 为什么软件架构是重要的

1. 提供了沟通的工具
2. 表现了最早期的决策集合
3. 表现了早期的设计决策
4. 促进/阻碍质量属性的实现
5. 引发有关潜在变更的讨论
6. 将更改分为三种类型：本地、非本地、架构
7. 是一种可迁移和可重用的抽象
8. 是产品通用性的基础，整个产品线共享一个架构
9. 可以通过体系结构集成独立开发的组件来开发系统

2.2. 软件需求

分为：

1. 功能需求：定义了系统必须做什么并且强调系统如何提供价值给涉众，意味着系统的行为。
2. 质量属性：系统应在其功能要求之上提供的整个系统的合乎需要的特性。
3. 约束：具有零自由度的设计决策，是已经做出预先指定的设计决策。

2.2.1. 软件需求（Software requirements）、质量属性（Quality attributes）、架构攸关的需求（ASR）的区别和联系

1. 软件需求包括质量属性
2. 质量属性是由软件的业务目标所决定，在功能性需求的基础上提供的整个系统的合乎需求的特性
3. ASR是对于体系结构有着深远影响的需求，肯定是软件需求的一部分

2.3. 质量属性详解

2.3.1. 如何进行质量属性场景建模

1. 识别质量属性：识别系统中重要的质量属性
2. 定义场景：一个质量属性场景通常包括：

1. 1. 刺激源（Source）：什么事件或条件触发了这个场景？
   2. 刺激（Stimulus）：实际的事件或条件是什么？
   3. 环境（Environment）：刺激发生的环境是什么？
   4. 响应（Response）：系统应该如何响应这个刺激？
   5. 响应度量（Response Measure）：如何度量响应是否成功？
   6. 工件（Artifact）：需求适用的整个系统或系统的一部分

1. 优先级排序：根据利益相关方的重要性和系统设计，对质量属性场景进行优先级排序
2. 场景分析：分析优先级场景，了解它们对系统架构和设计的影响
3. 将场景纳入设计：确保质量属性场景反映在系统的架构和设计决策中
4. 验证场景：在系统开发和测试过程中，验证系统行为是否符合定义的质量属性场景
5. 迭代和改进：随着系统的发展，重新审视质量属性场景，并根据需要更新它们。

示例：

（把表里的内容在上面的图里面画出来，据说Availability和Modifiability是重点）

2.3.2. 一些质量属性和对应的策略（Tactics）

（感觉大类背下来就行，里面细节的点我挑一点整理下来，据说Availability和Modifiability是重点）

2.3.2.1. Availablity（可用性）

1. Detect Faults（故障检测）

1. 1. Ping/Echo：使用Ping命令测试目标主机是否在线
   2. Heartbeat（心跳）：通过心跳信号检测系统或组件的运行状态

1. Recover from Faults（故障恢复）

1. 1. Preparation and Repair（准备和修复）：

1. 1. 1. Active Redundancy（主动冗余）：通过备用系统或组件实时替代发生故障的部分
      2. Passive Redundancy（被动冗余）：备用系统或组件在主系统故障时接管
      3. Rollback（回滚）：将系统恢复到之前的正常状态

1. 1. Reintroduction（重新引入）

1. 1. 1. Shadow（影子系统）：使用影子系统进行测试和故障隔离
      2. State Resynchronization（状态重新同步）：重新同步系统的状态

1. Prevent Faults（故障预防）：

1. 1. Removal from Service（移除服务）：将潜在的故障组件从服务中移除进行维护
   2. Transactions（事务处理）：使用事务机制保证操作的一致性和可靠性

2.3.2.2. Interoperability（互操作性）

（指的是分布式系统之间交换信息的能力）

1. Locate（定位）

1. 1. Discover Service（发现服务）：在系统中定位和发现可以提供所需服务的组件

1. Manage Interface（管理接口）：

1. 1. Orchestrate（编排）：协调多个服务和组件之间的交互，使它们能够顺利合作
   2. Tailor Interface（定制接口）：根据特定需求定制接口，以确保不同系统或组件之间能够兼容和互操作

2.3.2.3. Modifiability（可修改性）

1. Reduce Size of a Module（减少模块大小）

1. 1. split module（拆分模块）：将较大的模块拆分成多个较小的模块

1. Increase Cohesion（增加内聚性）：

1. 1. Increase Semantic Coherence（增加语义一致性）：确保模块内部的功能紧密相关

1. Reduce Coupling（减少耦合）：

1. 1. Encapsulate（封装）：将模块内部的实现细节隐藏起来，只暴露必要的接口
   2. Restrict Dependencies（限制依赖）：尽量减少模块对外部资源或其他模块的依赖

1. Defer Binding（延迟绑定）

1. 1. 在运行时而不是编译时确定模块之间的绑定关系

2.3.2.4. Performance（性能）

1. Control Resource Demand（控制资源需求）

1. 1. Prioritize Events（事件优先级）：根据事件的重要性设置优先级，优先处理高优先级时间
   2. Bound Execution Times（限制执行时间）：限制任务或操作的最大执行时间，确保系统在合理时间内做出响应

1. Manage Resources（管理资源）

1. 1. Increase Resources（增加资源）：增加系统资源，例如添加更多的CPU、内存或存储
   2. Introduce Concurrency（引入并发）：通过并行或并发处理提高系统性能

2.3.2.5. Security（安全性）

1. Detect Attacks（检测攻击）：

1. 1. Detect Intrusion（检测入侵）：识别系统或网络中未经授权的访问
   2. Detect Service Denial（检测服务拒绝）：识别拒绝服务攻击

1. Resist Attacks（抵御攻击）：

1. 1. Identify Actors（识别行为者）：确认访问系统的用户或实体的身份
   2. Authenticate Actors（认证行为者）：通过密码、证书等方式验证用户身份
   3. Authorize Actors（授权行为者）：基于身份验证结果，赋予用户适当的访问权限

1. React to Attacks（响应攻击）：

1. 1. Revoke Access（撤销访问权限）：在发现可疑活动后，立即取消相关用户或实体的访问权限
   2. Lock Computer（锁定计算机）：当检测到攻击时，锁定计算机以防止进一步的破坏

1. Recover from Attacks（从攻击中恢复）：

1. 1. Maintain Audit Trail（维护审计跟踪）：记录所有的操作日志，以便在攻击后进行分析和审查
   2. Restore（恢复）：从备份中恢复被破坏的数据或系统

2.4. Architecturally Significant Requirements（ASRs，架构攸关的需求）

2.4.1. ASR定义

架构攸关需求（ASR）是指对系统架构有深远影响的需求。这些需求的重要性和难度通常会显著影响系统的架构设计。如果没有这些需求，架构可能会有很大的不同。

2.4.2. ASR特点

1. 影响架构决策： ASRs通常决定了系统的整体架构设计，如采用的技术栈、设计模式和架构风格。
2. 高优先级： 相比其他需求，ASRs通常优先级更高，需要在早期架构设计阶段解决。
3. 包含质量属性： ASRs中常常包含关键的质量属性，这些属性对系统的整体结构和设计有深远影响。
4. 涉及对系统架构设计有重大影响的需求，可以是功能需求也可以是非功能需求。

2.4.3. 如何获取ASRs？

1. 从需求文档中收集ASR
2. 通过采访涉众来收集ASR：质量属性工作坊
3. 通过了解业务目标来收集ASR
4. 通过质量属性效用树（Utility Tree）来捕获ASR

3. 架构模式

3.1. 架构模式（Architecture Patterns）

分为Module Style、Component-Connector Style、Allocation Style三种

1. Module Style：是如何组织成一组实现单元的
2. Component-connector style：是如何组织成为一组具有运行时行为和交互的元素的
3. Allocation style：如何和环境中的非软件结构关联的

3.1.1. 定义

架构模式是一组在实践中反复出现的设计决策，具有可重用的已知特性，并用于描述一类架构。

架构模式建立了以下三者之间的联系：

1. 上下文 (Context)：世界中反复出现的常见情境，该情境会导致特定问题。
2. 问题 (Problem)：在给定上下文中出现的、经过适当概括的问题。
3. 解决方案 (Solution)：对该问题的成功架构解析，并经过适当抽象。包含元素+关系+约束。

（Broker好像考的挺多）

（MVC、Layered也考过）

3.1.2. Module Style

模式名称	上下文	好处	约束	局限性
分层模式（Layered Pattern）	分层模式定义了各层（提供一组有凝聚力的服务的模块分组）和各层之间的单向允许使用关系。该模式通常以图形的方式显示，即通过将代表各层的方框堆叠在一起。	提高了可修改性、可模块化、可维护性、可复用性	每个软件被分配到特定的一层；至少得有两层；不能有环状调用关系。	层的添加增加了系统的开销和复杂度；多层会降低系统性能

3.1.3. Component-Connector Patterns（组件-连接器模式）

3.1.3.1. 【重点】C&C本质（nature）是啥？

通过组件（Component）和连接器（Connector）的抽象，描述系统在运行时的动态交互结构和行为。它关注的是系统如何通过功能单元间的交互来完成工作。

模式名称	上下文	好处	约束	局限性
代理模式（Broker Pattern）	多个同步或异步交互的远程对象组成的系统，broker模式已定义了运行时组件 broker，它协调多个客户机和服务器之间的通讯。	提高了Client和Server之间的交互性、提高可伸缩性和可扩展性、解决了单体应用的性 能瓶颈、大规模集群的性能提高	客户端和服务器都只能和代理人连接。	单点性能会下降；代理增加了前期复杂度、可能成为通信的屏障、可能成为攻击的目标、难以测试。
MVC模式	MVC模式将系统分解成为三个组件：一个模型，一个视图，以及一个在视图和模型之间的控制器	提高了系统的可修改性、可测试性、可维护性、可复用性	模型、视图和控制器各自至少有一个实例；模型组件不能直接和控制器交互	对于有些用户界面可能不适用；复杂度较高
管道和过滤模式（Pipe-and-Filter Pattern）	数据从外部输入系统到输出到外部，将经过一系列由管道连接的过滤器，在此之中数据将被转换。	提高了可扩展性、可重用性、可维护性、可测试性、性能	管道将过滤器入口和出口连接；被连接的过滤器在传输的数据类型上必须达成一致；	不适用于交互式系统；不适用于长时间运行的计算；可能造成大量的计算
客户端-服务器模式（Client-Server Pattern）	客户端向服务端发起交互，按需调用服务端提供的服务并等待响应	可扩展性、性能、可维护性、安全性、可移植性	客户端通过请求/响应通道连接到服务端；服务端组件可能作为其他服务端的客户端	服务端可能成为性能瓶颈；服务端单点故障；如何定位功能比较复杂，难以变更。
点对点模式（Peer-to-Peer）	计算是通过合作的对等体来实现的，这些对等体通过网络向对方请求服务并提供服务。	多个节点同时提供服务，性能高；同一个数据多个副本，可用性高；	可能对以下方面施加限制： 任何给定对等体允许的连接数 用于搜索对等体的跳数 哪些对等体知道其他哪些对等体的信息	不能保证可用性，不会以后任何一个节点有权限；数据分布在不同节点，可能导致数据不一致；被攻击的可能性大，安全性不受保障
面向服务的模式（Service-Oriented）	计算是由一组合作的组件实现的，这些组件通过网络提供和/或消费服务。计算通常使用工作流语言来描述。	互操作性；可伸缩性	服务消费者连接到服务提供者，但可能使用中介组件（例如，ESB、注册表、编排服务器）。	复杂；无法控制独立服务的演化；中间件和性能有关，服务可能成为性能瓶颈
发布-订阅模式（Publish-Subscribe）	组件发布并订阅事件。当某一组件发布事件时，它将被通知到所有注册了的订阅者。	解耦发布者和订阅者； 可扩展性：可以轻松添加更多订阅者或发布者； 灵活性：订阅者可以选择性订阅感兴趣的主题，忽略不感兴趣的消息	约束可能限制哪些组件可以监听哪些事件，一个组件是否可以监听自己的事件，以及系统中可以存在多少发布-订阅连接器。	增加了消息传递的延迟；削弱了对消息的控制，消息的传递也不能保证。
共享数据模式（Shared-Data）	数据访问器之间的通信是由一个共享数据存储器来调解的。控制可以由数据访问者或数据存储发起。数据存储使数据持久化。	简化数据访问 保证数据一致性 减少数据冗余	数据访问器与数据存储交互。	共享数据的存储可能成为性能瓶颈；可能成为单点故障；数据的生产者和消费者可能过于耦合。

3.1.4. Allocation Pattern（分配模式）

模式名称	上下文	好处	约束	局限性
Map-Reduce模式	map-reduce模式提供了一个分析大型分布式数据集的框架，它将在一组处理器上并行执行。这种并行化可以实现低延迟和高可用性。map执行分析的提取和转换部分，reduce执行结果的加载。	可扩展性：易于添加实例 容错性：能够处理节点故障 灵活性：允许自定义map和reduce函数	待分析的数据必须作为一组文件存在 Map函数无状态，且彼此不进行通信 Map实例和Reduce实例之间唯一通信是Map发出的数据	如果不是大规模数据集，开销会较大；如果不能将数据集划分为大小相近的子集，将失去并行的优势；复杂度高
多层模式(Multi-Tier Pattern)	许多系统的执行结构被组织为一组组件的逻辑分组。每个分组被称为一个层级。组件的分组可以基于各种标准，如组件的类型，共享相同的执行环境，或具有相同的运行时目的。	分离关注点：将不同功能和责任分离到不同的层 可维护性：每一层可以独立开发和维护 可扩展性：可以独立扩展或更新某一层，不影响其他层	软件组件属于恰好一个层级	开销和复杂度高

3.2. 模式和策略（Patterns vs Tactics）

1. 策略比模式简单。他们使用单一的结构或机制来应对单一的架构需求。
2. 模式通常将多个设计决策组合到一个包中。
3. 模式和策略共同构成了软件设计师的主要工具。
4. 策略是设计的“构建块”，可以从中创建架构模式
5. 大多数模式包含几种不同的策略

3.3. SOA的基本原则

1. 服务契约
2. 服务封装
3. 服务重用
4. 服务组合
5. 服务自治
6. 服务解耦
7. 服务无状态

3.4. Layered和Multi-Layered区别

1. Layered Pattern是Module Style，而Multi-tier Pattern是Allocation Style
2. Layered Pattern是将任务拆解成一个个处于特定抽象级别的子层次，每层为下一层提供更高层次的服务，核心是关注点分离。
3. Multi-tier Patten中的层是逻辑的组合，没有层次模式的强依赖关系，在不同部署环境中分层不同但是软件完成的内容一致。

4. Architecture Design 架构设计

4.1. 通用设计（General Design Strategies）

1. Abstraction 抽象：使用抽象让设计师关注本身结构而不关心实现，比如将系统抽象为组件和连接器或者抽象为模块。
2. Generate & Test 生成并测试：将一个特定的设计看做是一个假设；根据测试路径生成测试用例
3. Decomposition 分解：针对某一个系统关注点分解后处理，比如将整个系统分解或将某个模块分解
4. Reusable Elements 重用元素：重用在设计过程中出现了可以复用的元素；重用现有架构
5. Iteration & Refinement 迭代精化：使用迭代的方法，例如ADD方法多次迭代直到满足所有ASR
6. Divide & Conquer 分而治之：将每个模块分别处理

4.2. 七类设计决策（Design decisions）

1. 职责分配：将大的职责进行分配
2. 协调模型：各部分之间的沟通、交互
3. 数据模型：数据格式、存储方式（缓存等）
4. 资源管理：CPU、网络、内存、时间等资源
5. 架构元素之间的映射：将架构元素如何映射到软件的实现上
6. 绑定时间决策：

1. 1. 系统的变化在什么时间点之前需要固定下来，在这个时间前系统还是可以变化的，在这个之后就不可以变化了
   2. 实际上我们希望绑定时间越往后越好，但是也就要付出相应的代价

1. 技术选择：选择系统的技术栈（在前面部分都确定后，可以选择的相对比较局限了就）

4.3. ADD方法步骤（2.0）

4.3.1. 输入输出

1. 输入：功能需求、质量属性、约束
2. 输出：软件元素、角色（相关职责的集合）、元素职责、元素属性、两个元素之间的关系

4.3.2. 步骤

1. 确认有足够的需求信息
2. 选择要分解的系统元素
3. 确定所选元素的ASR
4. 选择符合ASR的设计概念

1. 1. 找出设计关注点
   2. 列出可以替代的模式/策略
   3. 从清单中选出模式/策略
   4. 确定模式/策略与ASR之间的关系
   5. 捕获初步的架构视图
   6. 评估并解决不一致问题

1. 实例化架构元素并分配职责
2. 为实例化元素定义接口
3. 验证和完善需求，并使其成为实例化元素的约束
4. 重复进行，直到满足所有ASR

4.4. Architecture、Structure、Design三者区别

1. Design包含Architecture，Architecture包含Structure
2. Structure是静态的、逻辑的，是关于系统如何构成的
3. Architecture除了包含Structure，还会包含组件之间的关系，并定义一些动态的行为
4. Architecture是关于Design的，所有的Architecture都是Design，但不是所有的Design都是Architecture

5. Microservices Architecture 微服务架构

5.1. 概括性描述（理解）

微服务架构是把应用程序功能性分解为一组服务的架构风格，每一个服务都是由一组专注、内聚的功能职责组成。

微服务架构是一种将单体应用拆分为细粒度的服务，并使其运行在独立进程中，服务之间采用轻量级通信机制(如HTTP RESTfulAPI)进行交互的架构风格。这些服务围绕系统的业务能力构建，且可以通过全自动的部署机制进行独立部署。服务可以进行分布式管理，从而支持不同的编程语言进行开发和不同的数据存储技术进行存储。

5.2. 六大特性

i. 拆分服务--组件化 （通过进程间通信的方式变成独立单元）

ii. 团队围绕业务组织；

iii. 服务与服务之间遵循面向对象的高内聚低耦合

iv. 拆分后的分布式系统，服务数量变多，具有去中心化的特性；

v. 自动化的管理，依赖基础设施服务（主要是运维层面）

vi. 设计过程中针对质量属性的策略，核心是故障，保障服务等设计

5.3. 架构风格对比

【2019】微服务和SOA的区别，相同点

相同点：微服务和SOA都是分布式架构，微服务是SOA的一种扩展，都包含了服务契约、服务封装、服务重用、服务组合、服务自治和服务无状态等基本特点。

1. 微服务去掉了SOA架构中的ESB，采用轻量级通信机制(gRPC、REST)进行服务之间的通信。
2. 微服务的管理和部署结合DevOps实现自动化，可以对服务进行自动化部署和监控预警。
3. 微服务引入了API网关、对客户端屏蔽访问各项服务的问题。
4. 微服务引入了熔断器：避免出现服务失效或网络问题等导致的级联故障。

5.4. 微服务设计模式

	拆分模式	通信模式	部署模式	可观测模式
上下文	（自编）单体应用过于庞大，需要拆分成多个服务	（自编）各个服务搭建完成，彼此协作对外提供服务	微服务架构包含一组服务 每个服务都部署为一组服务实例，以实现吞吐量和可用性	多台机器上，多个服务和实例 请求跨越多服务实例，每个服务通过执行一个或多个操作处理请求 以标准化格式将操作写入日志文件，跟踪用户行为和代码异常 服务实例可能无法处理请求但仍在运行
问题	如何将应用拆分为微服务	如何避免故障蔓延到其他服务？ 如何在网络上发现服务实例的位置？ 如何处理外部客户端和服务的通讯？	如何部署？	如何理解用户和应用程序的行为并解决问题？ 如何检测正在运行的服务实例无法处理请求？
需求	高内聚 松耦合 单一职责原则 共同封闭原则 双披萨团队开发 团队自治	（自编） 降低通信开销 防止故障蔓延	服务使用各种语言、框架和框架版本编写 需要快速构建、独立部署和扩展服务 服务实例需要相互隔离 需要监控每个服务实例的行为、部署可靠 需要限制服务消耗的资源 尽可能经济高效地部署应用	（自编） 及时发现异常用户行为与服务的故障异常
模式列表	根据业务能力进行服务拆分 根据子域进行服务拆分	断路器 应用层服务发现 平台层服务发现 API Gateway	单主机部署多个服务实例 单主机部署单个服务实例 将服务部署到虚拟机 将服务部署到容器 服务部署平台 无服务器部署	日志聚合 审计日志 应用程序指标 分布式跟踪 异常跟踪 健康检查API

6. AI-native Application Architecture AI原生应用架构

6.1. 什么是 AI 原生应用架构？

AI 原生应用架构是为大模型应用量身打造的一种新型软件架构。它与传统软件架构的最大区别在于：

· 以“AI 模型”为中心

· 强调“Agent 智能体”的协作和自动推理、

· 强调“数据”的集中处理与利用（尤其是向量数据库）

· 借助“工具链”构建完整、高效、灵活的 AI 应用系统

6.2. AI 原生应用的关键组成

大模型、AI Agent、向量数据库、Prompt、RAG（检索增强生成）、Higress（AI 网关）、工具链生态

6.3. AI 原生应用的优点

· 快速构建智能应用

· 灵活组合不同模型和服务

· 数据驱动持续优化

· 安全合规可控

· 可观测性强，便于运维

7. Domain-Driven Design（DDD）领域驱动设计

会有一道设计题

· 领域模型包括实体、值对象、领域服务和领域事件

· 体现领域概念的领域模型包括实体和值对象

· 聚合作为边界封装实体和值对象，体现领域概念的完整性

· 资源库和工厂管理聚合的生命周期

7.1. DDD设计基本流程

首先第一步，根据业务诉求，提炼出整体的业务流程，同时拆解出里面的关键事件，角色，参与者等核心实例。整个拆解和梳理的方法论，目前业界有一些比较成熟的，比如事件风暴，四色建模法等，后面单独讲。

提炼完整个业务流程后，进入战略设计阶段，这个阶段主要是从全局和顶层的视角，把整个业务语义转换为结构化分层。通过领域和子域的划分，同时结合通用域、支撑域、限界上下文等设计，分解问题复杂度，其实就是前面说到的“分而治之”的思想。

接下来就会到具体的战术设计阶段，通过前面的战略设计阶段，已经把整个领域、边界、上下文等关键模块都梳理完成，现在就是从各个域中再次拆解更细粒度的模块，去指导最终的编码实现，这些更细粒度的模块包括实体、聚合、聚合根等。

最后就到了编码实现阶段，DDD有一个关键价值，叫做“设计即实现”，所以在战术阶段的设计，理论上是可以直接作用于代码的分层结构，如果架构和战术阶段有出入，说明之前的设计有问题，可以复盘重新推演。

7.2. 战略设计

7.2.1. 领域

领域（Domain）是指业务问题的特定领域范围，领域是对业务问题进行分解和组织的基本单位。

7.2.2. 子领域

1. 概念

指在一个大的领域中划分出的相对独立的子领域，通常代表一个独立的业务领域，具有特定的业务逻辑和功能需求。子域可以是整个系统的一个功能模块，也可以是一个独立的业务流程。

领域按照一定的业务规则细分，进而划分出多个子域，每个子域对应一个更小的业务范围。

2. 过程：把问题域逐步分解，降低业务理解和系统实现的复杂度。（分而治之）

7.2.3. 限界上下文

限界上下文体现了业务能力的纵向切分，体现了领域模型的知识语境。

限界就是领域的边界，而上下文则是语义环境。

· 定义：一个限界上下文指的是一个明确定义了特定业务领域所围绕的边界。不同的限界上下文之间可以是相互隔离的，每个上下文内部有其自己的语言和模型，之间需要通过明确定义的接口进行通信。

限界上下⽂在保证概念完整性的同时，能够提供完整的业务能⼒ ,它满⾜⾃治原则，遵循菱形对称架构，是应⽤架构的基础，可以独⽴进化。

7.3. 战术设计

7.3.1. 聚合

• 定义：

聚合是领域模型的概念边界。封装在聚合边界内的领域模型包括实体和值。它们组成一棵树，每棵树只能由一个根，且必须为实体，可称为根实体。

在聚合的内部，实体与值对象的协作完全遵循面向对象的行为协作模式，避免设计为贫血模型。根实体作为聚合的唯一出口与入口，通过它与外界协作。

• 作用：

①保证数据的一致性。

② 聚合是数据修改和持久化的基本单元，实现数据的持久化。

③ 实现微服务的"高内聚、低耦合"

• 特点：高内聚、低耦合

7.3.2. 领域事件

7.3.2.1. 领域服务职责

· ⽆状态的领域⾏为，相当于⼀个函数；

· 变化的领域⾏为，相当于策略模式的实现；

· 协调多个聚合；

· 访问外部资源

7.3.2.2. 领域事件特征

· 是过去发⽣的与业务有关的事实

· 具有时间点的特征，所有事件连接起来会形成明显的时间轴

· 是管理者重点关⼼的内容，缺少该事件会对管理与运营产⽣影响

· 会导致⽬标对象状态的变化，命名使⽤动词的过去时态

7.3.2.3. 如何识别领域事件

① 如果发生某种事件后，会触发进一步的操作，那么这个事件很可能就是领域事件。

② 领域事件可以切断领域模型之间的强依赖关系，事件发布完成之后，发布方不必关系事件处理是否成功，可以实现领域模型之间的解耦，维护领域模型的独立性和数据的一致性。领域事件可以解耦微服务。

7.4. 核心框架

7.4.1. 研发过程

7.4.2. 核心模式

7.4.3. 适用范围

项目制交付通常注重短期效率，资金来源通常也是基于合同制，比如某具体客户的转型预算:通常由临时团队负责交付，项目结束后交付团队就分散去负责下一个项目。

产品制交付注重长期提效，一个业务组件由固定的团队开发运维，迭代优化，持续改进，产品设计的理念也可以被用于组件设计，比如使用设计思维寻找组件的业务价值，业务变化点。

7.5. 可能会让分析:xx设计违反了xx原则，然后让给出更好设计，并且有简单的伪代码的实现（PPT有实例）

7.5.1. 迪米特法则

7.5.2. 隐私法则与最小知识法则

两个协作对象:

如果同时违背这两个原则，就会破坏封装，使得一个对象成为另一个对象的数据提供者。

如果同时遵循这两个原则，就能最大程度降低依赖(耦合)，使得两个对象之间产生良好的行为协作。

7.6. AI与DDD的双向赋能

AI for DDD：领域模型、代码⻣架与测试⽤例

DDD for AI：为 AI 明确逻辑输⼊、简化AI 模型训练范围

符合规范的需求文档 ——> AI 研发平台 ——> 可以工作的软件

8. Enterprise Architecture 企业架构

8.1. 企业架构的概念

企业架构指的是具有共同目标的组织集合体的基本组成部分及其内外部关系与设计、治理原则。

企业是指有共同目标的组织集合体。

企业架构处理的通常是规模上升带来的复杂度，取决于业务复杂度导致的系统复杂度。

8.2. 企业架构一般设计过程

1. 业务架构设计：

a. 战略设计：确定战略⽬标和主要措施，分解识别业务⽬标，拆分能⼒需求，形成战略能⼒聚类，形成组织设计（谁来⼲）

b. 业务设计与分析：通过流程模型、产品模型、数据模型组成并扩展为业务模型，定义了以提⾼⽣成效率和避免操作性错误为核⼼的⽤户体验模型，并对业务组件进⾏业务需求分析形成业务架构

2. 应用架构设计：设计应⽤构件和应⽤，进⾏应⽤分析，服务拆分等⽅法，识别并定义⽤例

3. 技术架构设计：包括物理构建设计和技术平台设计

4. 安全架构设计：满⾜安全要求的设计。选择安全⼯具

9. 补充

9.1. 为什么给架构决策做文档是重要的？

1. 避免重复过往步骤
2. 阐述该架构的优势所在
3. 强调对需求/目标的关键特性和重要性
4. 提供相关背景和上下文