👷 design(0.1): 更新应用架构的设计框架,设计模式以及领域驱动建模

更新应用架构的设计框架,设计模式以及领域驱动建模

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

Author: tonydeng

app-arch/domain-driven-design.md

@@ -1 +1,16 @@
 # 应用架构设计框架
+
+应用架构构建业务架构、数据架构、技术架构之间的关联关系。**应用架构以企业业务架构为基础，规划整个企业所有应用系统的蓝图**，将业务架构中业务流程、业务能力等落实到应用系统的具体功能和服务，并对数据架构的数据分析和管理提供诉求，对技术架构中涉及的开发平台、技术选型、基础设施、集成、安全等提出要求，指导后续架构的部署与构建。
+
+![应用架构的设计框架](images/Application-architecture-design-framework.png)
+
+> 图例：应用架构的设计框架
+
+应用架构的设计框架主要包括以下部分。
+
+- **应用核心设计**：对应用架构的核心内容进行设计，包括应用、领域服务、功能接口及对应的产品与解决方案等。
+- **应用系统设计**：应用对应的系统能力设计，确定系统的边界、定义、接口，包括系统对应的表现层、应用层、领域层、基础设施层。
+- **应用架构管理**：应用涉及的相关协同管理，包括应用共享、应用开发、应用集成等，也涉及一些技术组件。
+- **应用架构原则规范**：包括服务设计原则、服务分层原则、系统集成原则等，以及相关的开发规范、设计规范、设计工具等。
+- **应用架构行业参考**：包括通用的一些行业参考模型，提供企业参考、资产沉淀和复用。
+从以上可以看出，应用架构设计的核心是应用核心设计，而实际过程中领域驱动设计是非常重要的理论参考。

app-arch/framework.md

@@ -1 +1,25 @@
 # 企业IT架构概述
+
+企业IT架构承载着业务架构，并指导企业IT和具体项目的开展。**业务的开展依赖IT，而IT的需求来自业务**。
+
+## 业务架构向IT架构转化的过程
+
+在企业IT架构设计过程中，我们需要**关注IT与业务的关系，理解并转化业务方向，并进行正确的技术选型，提供IT的投资依据，结合数字化转型项目，提高企业业务和技术的核心竞争力**。
+
+![业务架构向IT架构转化的过程](images/The-transition-from-business-architecture-to-IT-architecture.png)
+
+> 图例：业务架构向IT架构转化的过程
+
+在业务架构向IT架构转化的过程中，业务架构为IT架构提供了企业业务的输入，通过对战略技术的转化，业务架构把企业的业务通过业务能力、业务流程及更细粒度的业务活动等业务需求具象化地展示出来。进而，IT架构中的**应用架构承接这些需求，通过领域驱动设计等设计方法，使用领域服务构建服务化能力，并通过服务化的功能接口等，逐步构建应用系统，同时结合业务发展，构建企业的产品和解决方案**。在整个过程中，**数据是核心，应用架构中构建的领域模型对数据架构中的数据模型进行输入，指导数据实体等数据分布和分析，并通过技术架构的数据存储进行具体的数据管理**。而应用架构产生的应用、产品、服务等内容通过技术架构提供的开发能力实施落地，比如使用微服务、云计算、云原生等应用服务开发方法，并通过技术架构中的基础设施、系统集成等完成整体技术底座的支撑和保障。
+
+## 企业IT架构总体框架
+
+企业IT架构主要包括应用架构、数据架构、技术架构，具体如下所示。
+
+![基于云原生体系的企业IT架构总体框架](images/Overall-framework-of-enterprise-cloud-native-IT-architecture.png)
+
+> 图例: 基于云原生体系的企业IT架构总体框架
+
+- **应用架构**：涵盖应用、服务、应用组件、功能组件、服务接口等。**核心是将业务架构的业务流程和服务翻译成人们可以看得懂的应用服务和服务流程，过程中涉及领域驱动设计、服务化、微服务等相关架构设计能力**。此外，**应用架构还包括系统、共享中心、产品、解决方案等层面的系统级抽象，这是整个IT架构的关键阶段**，决定着企业为客户提供的具体的应用服务功能。
+- **数据架构**：描述企业架构的**数据模型、数据分布、数据资产之间的结构和关系，是IT架构的核心**。数据架构与**应用架构的领域模型**密切相关，并与**技术架构的数据存储**紧密相连。数据架构通过数据标准、数据治理、管控流程和技术工具等方面进行制定，并协同业务架构、应用架构、技术架构层面的数据**形成统一、完整的数据标准**。
+- **云原生技术架构**：通过**构建企业开发平台、运维平台来协助系统统一管理，并结合敏捷交付、精益管理等管理开发和运维一体化的平台，协助应用和数据等数字化项目落地**。云原生体系主要涉及云原生基础设施、云原生应用平台、低代码开发平台、云原生技术组件，以及一些集成平台和安全平台的构建。

app-arch/images/Application-architecture-design-framework.png

@@ -1 +1,44 @@
 # 应用架构概述
+
+应用架构是对**企业所有应用系统、服务及它们之间交互关系的整体描述，反映应用系统如何支撑业务运行及未来业务发展，同时需要体现应用与技术、数据之间的关系**。
+
+应用架构是业务架构、技术架构、数据架构，以及企业业务、文化、组织等的成果体现方式，**核心是通过建模将业务流程和服务转化成应用系统层面的应用与服务等概念，决定了企业为客户提供的具体的应用服务功能**。
+
+## 应用架构的本质
+
+**应用架构的本质其实是建模的过程**。
+
+从现实世界到软件应用世界，是一个**不断抽象、不断建模的过程**，即从业务架构中抽象出业务能力和业务流程，进而对系统和应用建立模型，通过不同层面的模型设计，层层抽象，最终得到用户可以使用的系统，这个过程的**本质就是建模**。
+
+### 什么是模型（`Model`）？
+
+**模型指用一个较为简单的东西来代表另一个东西**。
+
+> 比如，科学模型中的数学公式极其简单并准确地表达了某种理论的计算原理。
+
+在架构设计中，**模型本身是业务需求的映射，以需求场景为输入，需要根据业务场景来进行验证和完善**；同时**模型是连接业务和应用系统的桥梁**，基于业务的理解，逐步展开，并产出应用中需要完成的服务、功能、接口等。另外，从落地层面，**代码是模型的印证**，最终模型在项目中通过具体的程序代码，把复杂的业务诉求构建成简单的模型，最终形成应用系统供用户使用。
+
+### 什么是建模（`Modeling`）？
+
+[百度百科是这样定义](https://baike.baidu.com/item/%E5%BB%BA%E6%A8%A1)的：**建模就是建立模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述**。
+
+[《大象：Thinking in UML》](https://m.douban.com/book/subject/10549583/)中是这样定义的：**建模是指通过对客观事物建立一种抽象的方法，用以表征事物并获得对事物本身的理解，同时把这种理解概念化，并将这些逻辑概念组织起来，构成一种对所观察的对象的内部结构和工作原理便于理解的表达**。
+
+建模的整个过程可大致分为业务建模和应用建模。
+
+- **业务建模的本质就是我们前文所讲的[业务架构](../biz-arch/)**，通过把业务的各种信息作为输入，建立企业业务的顶层视图，**核心是识别企业的业务能力和业务流程，以及各个业务活动的组成部分**，思考从用户使用的业务场景视角，企业该提供什么样的业务，大致的业务分类和业务逻辑是怎样的，应如何提供这些能力等，逐步通过业务能力和业务流程将业务抽象为“一张图”。
+
+- **应用建模是在业务建模的基础上，完成业务需求到应用系统模型之间的映射，最终设计出可以供用户使用并能具体解决用户问题的系统**。应用建模更**强调职责、依赖、约束关系**，用于指导研发的落地实现，所以这个过程的核心是**如何抽取核心概念，合理地划分这些模型层次，模型之间的边界是怎样的，如何控制模型之间的粒度**等。应用建模可以使用不同的方法，如面向对象方法、面向数据方法、面向领域设计方法等，目前**领域驱动设计是最受欢迎的设计方法**之一。
+
+我们再从业务架构和应用架构之间的关系来看这个建模过程，在**从业务架构中识别出业务能力和业务流程后，将基本组成部分抽象成业务活动，而这些业务活动通过应用架构中的模型和服务进行映射**，在此过程中，应用架构通过领域模型和领域服务，对业务能力和业务流程进行了翻译和关联，最终设计出相关的功能，并逐步抽象成产品和解决方案。
+
+## 应用架构的价值
+
+应用架构的价值主要体现在以下几点。
+
+- 应用架构作为**企业IT架构的核心，连接业务架构中业务能力、业务流程和业务需求，也能够连接数据架构的数据管理和使用，同时提出对技术架构和IT基础设施的要求**。
+- 应用架构**向业务部门提供整体IT应用系统的服务和功能，确保将来的应用与业务需求一致，并保持整体架构的连贯性**，对企业系统孤立、功能重复建设、灵活度差、难以共享等问题进行整合和优化。
+- 应用架构对**应用系统和服务的整体功能进行统一规划，建立企业应用系统的总体视图**。同时，万物皆服务，以服务为中心的应用架构可以解决企业在开发、部署、运维、集成等过程中面临的问题。
+- 应用架构**区分企业共享部分与定制化部分**，经过应用架构的**分层设计，将通用、成熟的功能进行共享下沉，将个性化、特殊的功能开放到更前端的业务部门**，便于功能的灵活扩展和业务的快速应变。
+- 应用架构为**企业产品化提供支持**。经过应用的能力设计和服务识别，为企业进一步优化产品和相应的解决方案提供基于架构视角的主要参考。
+- 应用架构**协助团队沟通**。通过维**护统一、便于理解的应用视图**，各业务和技术团队可以保持同频和一致，防止各部门进行重复建设。

app-arch/images/DDD-Layer-Node.png

@@ -1 +1,103 @@
 # 应用架构常用模式
+
+应用架构常用模式主要有以下几种。
+
+## 集中式架构
+
+集中式架构又称单体架构，传统企业根据各个业务部门的需求，开发了多个“烟囱式”系统，这种架构模式有很多弊端，在一些传统企业中还存在。
+
+## SOA（面向服务架构）
+
+企业采用企业服务总线（ESB）来解决多系统之间复杂的接口交互模式，也就是传统的SOA模式。而随着互联网企业的发展，采用去中心化、去IOE的分布式服务架构，不需要ESB作为中心节点，而是进行直接发现和调用，以解决中心化服务扩展难、不适合互联网大流量要求快速响应的痛点。
+
+[The Open Group的面向服务架构 (SOA) 工作组](https://www.opengroup.org.cn/service-oriented-architecture-soa-working-group)提出了一个[SOA架构的参考模型](http://www.opengroup.org/soa/source-book/soa_refarch/index.htm)，主要包括：
+
+![SOA参考应用架构](images/SOA-refers-to-application-architecture.png)
+
+> 图例：SOA参考应用架构
+
+SOA参考应用架构，具体包括以下几个层面。
+
+- **基础设施服务**：由操作系统和后台的应用系统组成，能够被系统组件调用，实现IT系统服务功能，并确保服务的质量，为各层次的系统提供数据支持。
+- **服务总线**：：通常由ESB系统提供路由、多协议、转换等,服务在这里注册和发现，也可以通过组合形成组合服务,并且通过对服务的服务组合和编排实现业务流程。
+- **关键服务组件**：由服务使用者组成，构建前台的访问应用。
+- **开发工具**：提供SOA的相关开工具，如WSDL等
+- **管理工具**：提供服务质量（QoS）服务，包括安全、管理和基础设施监控等。
+
+**SOA并不是推倒重建企业的系统，而是在现有的系统之上进行包装服务，建立标准结构，方便互通和调用**。SOA也使得架构设计的过程从面向对象、面向组件的设计方法过渡到面向服务的设计方法，其强调以服务为中心的设计理念，接口和实现分离、服务提供和服务使用分层的设计思想。
+
+## 事件驱动架构
+
+事件驱动架构（Event Driven Architecture，EDA）以SOA为基础，以事件为单位进行各种处理。事件驱动的核心是事件，事件是历史，是事实，是已经发生的事。
+
+![事件驱动架构示意图](images/event-driven-architecture-diagram.svg)
+
+> 图例：事件驱动架构示意
+
+事件由事件源生成，并通过事件管理器进行发布，各种事件的订阅方根据需要进行订阅消费，可以直接处理该事件，或者即时转给其他订阅方，同时事件作为一种业务数据的载体，可以进行存储，从而在以后进行处理。
+
+![EDA概念示意](images/EDA-architecture-schematic.png)
+
+> 图例：事件驱动概念示意
+
+事件驱动系统通常是异步的，事件生产者向事件管理器发布事件，如果事件消费者不可用，事件管理器将保留这个事件，之后再次转给事件消费者。
+
+事件生产者与事件消费者相对独立且解耦，事件生产者不需要知道哪个消费者会接收消息。事件消费者彼此之间也互相解耦，每个消费者都可以接收全部或者部分消息。因此，事件驱动架构的系统更适用于包含较多未知因素的环境或者异步的环境，通过构建分布式高可用架构，提供事件生产者和事件消费者相对灵活解耦的能力。事件驱动架构适用于多种场景，比如有多个子应用且处理相同事件，需要实时处理大量数据，有复杂的事件处理等。
+
+![EDA领域事件](images/EDA-domain-events.png)
+
+> 图例: EDA领域事件
+
+从领域设计角度，事件驱动架构也有广泛应用，比如基于事件风暴的分析方法。其中，事件源和订阅者都是具体的领域实体，事件管理器可以作为基础设施的一部分技术组件，这个过程会借助消息中间件来进行能力提供。
+
+## 微服务架构
+
+随着互联网技术的发展，SOA技术进一步进化为以微服务为主流的分布式服务架构。微服务是一种分布式架构模式，微服务架构凭借其简单清晰、灵活可扩展、独立部署等优势，逐渐成为分布式架构的主流。微服务将大型复杂软件应用拆分成多个微小的服务，服务之间是松耦合的，每个服务描述一个小业务，可以独立地进行升级、部署、扩展和重新启动等流程，并通过接口契约、标准协议等保持彼此互通。
+
+微服务架构由SOA演化而来，是SOA的一种特殊实现方式，突出将服务划分为更细粒度的微服务，按照业务领域划分，强调服务编排、服务治理、自动化运维，并具备高可用、性能要求、分布式事务一致等特点。
+
+关于微服务是什么，转述[Martin Flower 大神的系统阐述](https://www.martinfowler.cn/microservices/)：
+
+- 微服务是一种架构风格，也是一种服务
+- 微服务的颗粒比较小，一个大型复杂软件应用由多个微服务组成，比如Netflix目前由500多个的微服务组成
+- 微服务采用UNIX设计的哲学，每种服务只做一件事，是一种松耦合的能够被独立开发和部署的无状态化服务（独立扩展、升级和可替换）。
+
+![微服务架构示例](images/Sample-microservice-architecture.jpeg)
+
+> 图例：微服务架构示例
+
+与集中式架构相比，微服务有降低系统复杂度、提高迭代效率、促进团队沟通、弹性扩展、容错能力、独立部署、可扩展性、跨语言编程等很多优点，这里挑选几个进行说明。
+
+- **提高迭代效率**：支持细粒度的独立迭代和发布，速度快。由于微服务架构中的每个小型服务是独立部署的，可以单个服务进行缺陷修复或者特性变更，无须重新部署整个应用程序，一旦发现缺陷，就立刻回滚服务。
+- **促进团队沟通**：单个小型服务仅需要一个小的开发团队就可以完成开发、测试和部署工作。相比之下，更大的团队通常意味着更低的沟通效率、更高的管理开销。
+- **容错能力**：当系统出现问题时，将仅影响单个小型服务，不一定导致整个应用程序中断；同时对应的数据也将会进行隔离，风险明显降低。
+- **可扩展性**：每个小型服务都支持独立水平扩展，无须扩展整个应用程序，资源的利用率高，扩展快速。每个小型服务都可以独立进行服务升级，并且结合持续集成工具可以进行持续发布，快速完成服务升级和发布流程。
+
+微服务架构有很多好处，不过也存在以下一些挑战。
+
+- **设计的复杂性**：与传统架构的应用程序相比，微服务架构的组件更多。服务数量多意味着部署和管理的工作量更大，还需要考虑分布式系统的复杂性和分布式事务的处理难度。
+- **开发、测试、部署难度**：当服务拆分后，几乎所有功能都会涉及多个服务，所依赖的其他独立服务增多，此时处理好服务间的依赖关系成为关键。原本单个程序的测试会变为服务间调用的测试。测试变得更加复杂。
+- **运维难度**：由于可能采用不同的语言和框架，应用程序可能变得难以维护。整个应用分散成多个小型服务，这导致问题定位更加困难，同时可能增加服务间的通信量。
+- **数据一致性**：每个小型服务都仅负责各自相关的数据持久性，因此不同服务间的数据一致性很难达到。
+
+## 云原生架构
+
+分布式架构的出现是为了解决应用难以开发和维护的问题。
+
+- **垂直拆分**：把按业务领域拆分为**多个松耦合的独立应用**，各自独立部署和维护。
+- **水平拆分**：把**通用的、共性**的应用进行分层沉淀，**形成共享的服务能力**，这样可以对性能稳定性等问题进行统一处理和优化，防止重复开发。
+
+如今，架构朝着越来越轻量化、能力越来越下沉、应用越来越灵活的方向发展，到云原生时代达到了新的高度。
+
+**云原生将云应用中的非业务代码进行最大化的剥离，关注点分离，让云来负责原有的大量非功能特性需求，如可靠性、扩展性、可观测性、弹性、轻量、敏捷、自动化等**。
+
+同时，有很多企业也在尝试“双IT架构”，即以云原生架构来应对敏态业务的快速变化，以及传统的基于ESB方式的架构应对稳态内部系统的管理，二者相互结合并互补。
+
+## 扩展阅读
+
+- [微服务体系结构设计 - Microsoft](https://learn.microsoft.com/zh-cn/azure/architecture/microservices/)
+- [微服务评估和准备情况 - Microsoft](https://learn.microsoft.com/zh-cn/azure/architecture/guide/technology-choices/microservices-assessment)
+- [设计微服务体系结构 - Microsoft](https://learn.microsoft.com/zh-cn/azure/architecture/microservices/design/)
+- [适用于微服务体系结构的 CI/CD - Microsoft](https://learn.microsoft.com/zh-cn/azure/architecture/microservices/ci-cd)
+- [使用域驱动设计将整体应用程序迁移到微服务 - Microsoft](https://learn.microsoft.com/zh-cn/azure/architecture/microservices/migrate-monolith)
+- [微服务应用程序的统一日志记录 - Microsoft](https://learn.microsoft.com/zh-cn/azure/architecture/example-scenario/logging/unified-logging)