📝 docs(0.1): 添加技术架构内容

添加技术架构内容

Signed-off-by: Tony Deng <[email protected]>

Author: tonydeng

Diff for: SUMMARY.md

@@ -69,6 +69,14 @@
 ## 第六部分 技术架构设计
 
 * [技术架构设计](tech-arch/README.md)
+  * [技术架构概述](tech-arch/overview.md)
+  * [技术架构设计框架](tech-arch/framework.md)
+  * [技术架构常用模式](tech-arch/patterns.md)
+  * [技术架构设计原则](tech-arch/principles.md)
+  * [技术架构制图](tech-arch/diagram.md)
+  * [技术基础设施上云](tech-arch/cloud.md)
+  * [技术架构典型技术选型](tech-arch/technology.md)
+  * [技术架构最佳实践](tech-arch/best-practice.md)
 
 ## 第七部分 企业架构实践
 

Diff for: app-arch/images/Port-adapter-architecture.png

@@ -93,4 +93,14 @@ TAM这个模型既没有根据DDD给出分析的过程，也没有给出具体
 
 > 图例：店铺子应用系统示例
 
-首先，我们做准备工作，从业务架构的业务流程和业务能力出发。店铺系统是电商平台的一部分，主要面向买家、卖家及平台运营者。这里对卖家进行分析，可以看到主要涉及注册、开店、店铺装修、店铺营销及店铺推广，同时我们从业务能力中识别了一些关键的业务活动，如注册时提交资质审核资料，开店时创建店铺等。其次，我们初步分析出一些领域，包括店铺域、商品域、库存域、营销域等。再次，我们进行领域模型的设计，结合DDD等方法，可以得出店铺基本信息、店铺类目、店铺库存、店铺商品、店铺装修、店铺运营等基本领域实体，并且建立它们之间及它们与其他领域模型的关系。最后，我们根据DDD的上下文，对店铺域和其他域（如商品域、装修域、营销域）进行上下文分析，并建立各自的领域服务及彼此之间的交互关系。在完成店铺应用系统的核心设计后，我们可以按照这个思路来构建其他应用，并逐步构建整体的企业应用架构。
+首先，我们做准备工作，从业务架构的业务流程和业务能力出发。
+
+店铺系统是电商平台的一部分，主要面向买家、卖家及平台运营者。这里对卖家进行分析，可以看到主要涉及注册、开店、店铺装修、店铺营销及店铺推广，同时我们从业务能力中识别了一些关键的业务活动，如注册时提交资质审核资料，开店时创建店铺等。
+
+其次，我们初步分析出一些领域，包括店铺域、商品域、库存域、营销域等。
+
+再次，我们进行领域模型的设计，结合DDD等方法，可以得出店铺基本信息、店铺类目、店铺库存、店铺商品、店铺装修、店铺运营等基本领域实体，并且建立它们之间及它们与其他领域模型的关系。
+
+最后，我们根据DDD的上下文，对店铺域和其他域（如商品域、装修域、营销域）进行上下文分析，并建立各自的领域服务及彼此之间的交互关系。
+
+在完成店铺应用系统的核心设计后，我们可以按照这个思路来构建其他应用，并逐步构建整体的企业应用架构。

Diff for: app-arch/reference-design.md

@@ -1,3 +1,3 @@
 # 技术架构设计
 
-本章主要介绍数据架构的设计框架、设计方法、设计步骤，以及典型的数据架构技术、设计原则，并给出一些通用的数据架构参考设计，最后讨论云原生时代数据架构技术体系。
+在企业架构中，技术架构是支撑整个企业架构体系的技术部分，也是企业架构中IT架构的最后架构阶段。本章我们首先学习什么是技术架构，技术架构设计框架、常用模式、设计原则，以及技术架构制图；然后讨论技术基础设施上云、技术平台典型技术；最后讨论一些技术架构最佳实践。

Diff for: model/ea-practices.eapx

@@ -0,0 +1 @@
+# 技术架构最佳实践

Diff for: tech-arch/README.md

@@ -0,0 +1 @@
+# 技术基础设施上云

Diff for: tech-arch/best-practice.md

@@ -0,0 +1,76 @@
+# 技术架构制图
+
+在架构设计领域，架构制图是针对系统架构某一个方面的一种描述，将系统的技术方案、技术选型通过视图的方式进行展现。架构制图可以帮助团队内部和团队之间消除沟通歧义，提升协作效率。一图胜千言，无图无真相。图是直观而形象的，顺应了人类与生俱来的视觉识别本能，一张图所能传达的信息非常多。常见的技术架构制图有功能架构制图、系统分层架构制图、系统链路架构制图、部署架构制图、开发架构制图等。
+
+## 架构制图的原则
+
+国际上对架构描述设立了专门的标准（ISO/IEC/IEEE 42010:2011），架构制图是架构的载体，从制图本身角度，架构制图需要关注以下几个方面。
+
+- **深刻理解制图目标**：架构制图需要有明确的目标，需要准确、完整、清晰、一致、简洁。
+- **明确受众及关注点**：比如业务、产品、开发、测试、运维、外部客户、行业专家等。
+- **考虑全面，有所侧重**：架构制图需要跳出图本身，全面展示涉及的内容，避免“只见树木，不见森林”；同时需要针对受众和关注点有所侧重，略去与当前视图无关的细节。
+- **充分采用设计方法**：建议采用结构化思维，比如金字塔原理、结论先行、以上统下、归纳分组、逻辑递进。
+- **采用多种架构视图**：可以采用不同的视图来进行描述，比如从工程制图角度，有主视图、俯视图、左视图等。
+- **遵守统一的图例规范**：比如UML中泛化、聚合、组合、依赖等关系的表达，以及各种方框、虚实线、箭头的含义，特别是组件之间的交互方式，比如同步或异步。
+- **持续优化迭代**：与软件一样，架构制图也有版本，核心是表达清楚图的内容，突出最重要的地方，架构制图的粒度、类别、内容等可以逐步完善。
+
+## 架构制图的方法
+
+### UML
+
+UML（Unified Modeling Language）是统一建模语言的简称，它是一种由一整套图表组成的标准化建模语言。UML用于帮助系统开发人员记录软件系统的产出。UML主要使用图形符号来表示软件项目的设计，帮助项目团队沟通和进行软件设计。
+
+UML总共包含十几种不同类型的图，可以覆盖软件设计领域各种制图需求，主要分为如下两大类图。
+
+![UML分类](images/UML分类.png)
+
+> 图例: UML分类
+
+- **结构图（Structural Diagrams）**：通过对象、属性、操作和关系等，强调系统的静态结构，包括类图（Class Diagram）、组件图（Component Diagram）、部署图（Deployment Diagram）、对象图（Object Diagram）、包图（Package Diagram）、组合结构图（Composite Structure Diagram）。
+- **行为图（Behavioral Diagrams）**：通过展示对象之间的协作关系及对象内部的状态改变，强调系统的动态行为，包括用例图（Use Case Diagram）、活动图（Activity Diagram）、序列图（Sequence Diagram）、状态机图（State Machine Diagram）、通信图（Communication Diagram）、交互概述图（Interaction Overview Diagram）、时序图（Timing Diagram）。
+
+下面简单介绍几种常用的UML制图。
+
+- **类图（Class Diagram）**：类图是一切面向对象的核心建模工具，描述系统中对象的类型及它们之间存在的各种静态关系。
+- **组件图（Component Diagram）**：组件图描述组件如何连接在一起以形成更大的组件或软件系统。它展示了软件组件的体系结构及它们之间的依赖关系。
+- **用例图（Use Case Diagram）**：用例图从用例的角度描述系统的功能需求，它是系统预期功能（用例）及其环境（参与者）的模型。
+- **活动图（Activity Diagram）**：活动图用于展示工作流程，它支持选择 （Choice）、迭代（Iteration）和并发（Concurrency）。活动图描述目标系统的业务流程。
+- **状态机图（State Machine Diagram）**：状态机图描绘允许的状态和转换，以及影响这些转换的事件，有助于可视化对象的生命周期管理。
+- **序列图（Sequence Diagram）**：序列图根据时间序列展示对象如何进行协作。它展示了在用例的特定场景中，对象如何与其他对象进行交互。
+
+对于通用的一些UML原则，[《码出高效：Java开发手册》](https://m.douban.com/book/subject/30333948/)给出了比较详细的介绍，这里挑选并提炼其中几条。
+
+- 在需求分析阶段，如果与系统交互的对象超过一类并且相关的用例超过5个，则使用用例图来表达更加清晰的结构化需求。
+- 如果某个业务对象的状态超过3个，则使用状态机图来表达并且明确状态变化的各个触发条件。
+- 如果系统中某个功能的调用链路上涉及的对象超过3个，则使用时序图来表达并且明确各调用环节的输入与输出。
+- 如果系统中模型类超过5个，并且存在复杂的依赖关系，则使用类图来表达并且明确各类之间的关系。
+- 如果系统中超过2个对象之间存在协作关系，并且需要表示复杂的处理流程，则用活动图来表示。
+- 谨慎使用继承的方式进行扩展，优先使用聚合或组合的方式。
+- 在进行系统设计时，根据依赖倒置原则，尽量依赖抽象类与接口，这样有利于扩展与维护，需要注意的是，应对扩展开放，对修改闭合。
+- 在系统设计阶段，共性业务或公共行为抽取出来公共模块、公共配置、公共类、公共方法等，避免出现重复代码或重复配置的情况。
+
+### “4+1”视图模型
+
+1995年，Philippe Kruchten发表了题为“The 4+1 View Model of Architecture”的论文，引起了业界的关注。此论文提出了一种用来描述软件系统体系架构的模型，以架构为中心场景驱动和迭代开发等方式实现设计。“4+1”视图模型基于不同项目干系人，从4种基础视图和场景方面来描述软件需求。
+
+![RUP 4+1模型](images/RUP-4+1.gif)
+
+> 图例：“4+1”视图模型
+
+- **场景（Scenarios）**：场景用于描述系统的参与者与功能用例间的关系，反映系统的最终需求和交互设计，通常用用例图表示。
+- **逻辑视图（Logical View）**：逻辑视图用于描述系统软件功能拆解后的组件关系，反映系统整体组成与系统构建过程，通常用组件图和类图表示。
+- **物理视图（Physical View）**：物理视图用于描述系统软件到物理硬件的映射关系，反映系统的组件部署关系，通常用部署图表示。
+- **流程视图（Process View）**：流程视图用于描述系统软件组件之间的通信时序、数据的输入和输出，反映系统的功能流程与数据流程，通常用时序图和活动图表示。
+- **开发视图（Development View）**：开发视图用于描述系统的模块划分和组成，以及细化到内部包的组成设计，反映系统开发实施过程，通常用组件图和包图表示。
+
+## C4模型
+
+C4模型来自[《程序员必读之软件架构》（Software Architecture for Developers）](https://item.jd.com/10026523364580.html)一书，C4模型是一种“抽象优先”的架构制图方法，它是受[UML](#uml)的启发而开发出来的，但相对而言，C4模型更加简单和轻量，只包含少量的一组抽象和图表，易于学习和使用，如图7-4所示。
+
+![C4模型示意图](images/C4.png)
+
+> 图例：C4模型示意图
+
+C4代表**上下文（Context）**、**容器（Container）**、**组件（Component）**和**代码（Code）**分层的图表，可以用这些图表来描述不同缩放级别的软件架构，每种图表适用于不同的受众。
+
+C4模型最关键的思想就是自上而下对系统的静态结构进行逐级拆分，依次描述各层次对象的职责、关系和外部依赖。此外，它还可以包含动态视图、部署视图等补充视图。举个例子，一个软件系统由多个容器（如数据库、应用）组成，一个容器由多个组件组成（如微服务和技术组件），一个组件由多个代码（如接口类、实现类、领域对象类）结构组成。

Diff for: tech-arch/cloud.md

@@ -0,0 +1,13 @@
+# 技术架构设计框架
+
+技术架构涉及技术架构规划、技术平台、基础设施，以及技术架构标准原则、最佳实践等。
+
+![技术架构设计框架总览](images/technical-architecture-framework-overview.png)
+
+> 图例：技术架构设计框架总览
+
+- **技术架构规划**：对技术架构统一规划的指导，包括架构模式、架构方法、架构制图等。
+- **技术平台**：技术架构的平台组件能力，包括开发平台、数据平台、移动平台、低代码平台等，以及核心的典型技术，如服务治理、监控告警、流量调度、消息服务、缓存等。
+- **基础设施**：支撑技术架构的基础设施，比如计算、存储、网络、安全及云原生基础设施等，可以充分考虑企业上云相关技术。
+- **技术架构标准原则**：企业技术方向性的通用原则，如通用技术原则、技术框架原则、服务开发设计原则、架构制图原则等。
+- **技术架构最佳实践**：技术架构典型的实践，如一致性、高并发、高可用、安全生产、压测、秒杀、企业上云等。

Diff for: tech-arch/diagram.md

@@ -0,0 +1,16 @@
+# 技术架构概述
+
+技术架构也是我们常说的软件架构、系统架构，是**将业务需求和应用功能转变为技术实现的过程**。技术架构在软件开发过程中应用得比较普遍，受到广大技术人员的普遍关注，它是**有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计**。技术架构可以帮助我们梳理系统边界、识别系统需求、识别系统风险和问题优先级、确定技术方案和路线，让团队之间达成共识且相互约束，并指引团队适应业务和技术的变化。
+
+在企业架构中，技术架构是支撑整个企业架构体系的技术部分，也是企业架构中IT架构的最后架构阶段。技术架构以业务架构中的业务需求、业务能力、业务流程为指导，是从应用架构和数据架构的具体形态导出的对企业数字化系统和IT基础设施进行整体部署的一组技术标准规范、原则和最佳实践，并包含相关的技术选择标准、产品选择方案、技术实施路线等，**目标是优化整个企业的IT运行环境，实现IT对业务服务高效率地交付**。
+
+从广义上来讲，技术架构涉及技术研发的方方面面，**包括业务、数据、应用对应的软硬件能力，比如IT基础设施、中间件、网络、通信等**。同时，技术架构从**技术上指导应用系统的开发、部署、测试、交付、运维等，提出公共性、支撑性的指导，推进资源共享和系统协同，发挥现有资源和基础设施的效用，提升业务系统的互操作性**。技术架构解决的问题包括技术分层、技术框架选择、开发语言选择、非功能性需求实现等。
+
+## 技术架构的价值
+
+技术架构的主要价值有以下几点。
+
+- **理解对齐，形成共识**：软件系统是为了实现用户需求，特别是针对企业架构，不同的人有不同的视角，技术架构需要将业务架构、应用架构、数据架构的需求转换成技术人员可以理解的技术语言。**需求的实现往往可以有多种途径，如何选择途径？如何拆分系统？选择技术A还是技术B？这些都需要通过技术架构描述并记录下来，让大家理解对齐，形成共识**。
+- **标准规范，术语统一**：软件开发的不确定因素很多，特别是大型企业的技术落地过程，往往有多种技术规范和标准，包括行业通用的和企业内部的，如开发规范、部署规范、稳定性保障规范等。同时，在技术层面有很多术语，不同的人有不同的理解，**技术架构需要定义和解释清楚系统中涉及的关键概念，特别是非功能特性的选择和技术方案，并在整个架构设计和描述过程中使用标准和一致的术语**。
+- **言之有物，资产沉淀**：如同讨论产品交互时对照产品原型图，讨论代码Review时需要看代码一样，技术架构也有相应的实物，即架构制图（简称架构图）。**架构图是软件开发的高层次抽象，是架构持续演进的具体承载，也是技术团队的核心资产，对系统开发、新人培养等具有重要的作用，是技术团队的灵魂所在**。
+- **团队协同，明确分工**：技术架构提供企业更有效地管理研发的流程，方便团队协同，比如通过构建企业开发平台、运维平台来协助系统的统一管理，进而结合上层应用架构、数据架构的落地，通过**新技术（如云原生技术、容器化技术、敏捷交付、精益管理等软件工程管理技术）构建开发和运维一体化的平台，清楚地定义各团队的分工边界，确保业务需求和应用功能的稳定落地**。