目录

领域驱动实践总结二:架构分析与代码设计

一、微服务架构模型的对比与选择

（一）整洁架构

（二）六边形架构

（三）DDD 分层架构

1.用户接口层

2.应用层

3.领域层

4.基础层

5.从三层架构向 DDD 分层架构演进

（四）三种微服务架构模型的对比和分析

二、领域驱动设计分层架构与微服务代码模型

（一）代码模型总目录结构

1.微服务一级目录结构

2.用户接口层目录结构、职能和代码形态

3.应用层目录结构、职能和代码形态

4.领域层目录结构、职能和代码形态

5.基础层层目录结构、职能和代码形态

（二）应用层的领域对象分析

1.实体方法的封装

2.领域服务的组合和封装

3.应用服务的组合和编排

（三）领域层的领域对象分析

1.设计实体

2.找出聚合根

3.设计值对象

4.设计领域事件

5.设计领域服务

6.设计仓储

（四）代码模型强调内容

第一点：聚合之间的代码边界一定要清晰。

第二点：你一定要有代码分层的概念。

三、正确理解微服务的边界

（一）逻辑边界

（二）物理边界

（三）代码边界

四、正确认识服务和数据在微服务各层的协作

（一）正确认识服务的协作

1. 服务的类型

2. 服务的调用（三类主要场景）

微服务内跨层服务调用

微服务之间的服务调用

领域事件驱动

3. 服务的封装与组合

（二）正确认识服务数据的协作

1.基础层数据协作

2.领域层数据协作

3.应用层数据协作

4.用户接口层数据协作

5.前端应用数据协作

参考书籍、文献和资料

领域驱动实践总结二:架构分析与代码设计

领域驱动设计DDD是一种设计思想，它可以同时指导中台业务建模和微服务设计(中台本质是业务模型，微服务是业务模型的系统落地)，领域驱动设计强调领域模型和微服务设计的一体性，先有领域模型然后才有微服务，而不是脱离领域模型来谈微服务设计。

微服务拆分困境产生的根本原因:不知道业务或者微服务的边界到底在什么地方。

DDD 核心思想:通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。

对于领域驱动设计的学习做的总结主要写三篇博客，主要包括三部分:基本理论总结与分析、架构分析与代码设计、具体应用设计分析，主要参考的资料为极客时间的欧创新架构师的《DDD》实战，其他参考书籍在文章下方的参考书籍中。

本次主要总结DDD架构分析与代码设计：

一、微服务架构模型的对比与选择

微服务架构模型现有的选择模型包括：整洁架构、CQRS 和六边形架构、DDD 分层架构等。

（注：CQRS架构之前博客中有讲，本次不做分析）

每种架构模式虽然提出的时代和背景不同，但其核心理念都是为了设计出“高内聚低耦合”的架构，轻松实现架构演进。

DDD 分层架构的思想使架构边界变得越来越清晰，它在微服务架构模型中，占有非常重要的位置。建议选择DDD 分层架构。

（一）整洁架构



在整洁架构里，同心圆代表应用软件的不同部分，从里到外依次是领域模型、领域服务、应用服务和最外围的容易变化的内容，比如用户界面和基础设施。

整洁架构最主要的原则是依赖原则，它定义了各层的依赖关系，越往里依赖越低，代码级别越高，越是核心能力。外圆代码依赖只能指向内圆，内圆不需要知道外圆的任何情况。

（二）六边形架构



六边形架构的核心理念是：应用是通过端口与外部进行交互的。

也就是说，在下图的六边形架构中，红圈内的核心业务逻辑（应用程序和领域模型）与外部资源（包括 APP、Web 应用以及数据库资源等）完全隔离，仅通过适配器进行交互。它解决了业务逻辑与用户界面的代码交错问题，很好地实现了前后端分离。

六边形架构各层的依赖关系与整洁架构一样，都是由外向内依赖。

六边形架构的一个端口可能对应多个外部系统，不同的外部系统也可能会使用不同的适配器，由适配器负责协议转换。这就使得应用程序能够以一致的方式被用户、程序、自动化测试和批处理脚本使用。

（三）DDD 分层架构

从上到下依次是：用户接口层、应用层、领域层和基础层。



1.用户接口层

用户接口层负责向用户显示信息和解释用户指令。

这里的用户可能是：用户、程序、自动化测试和批处理脚本等等。

2.应用层

应用层是很薄的一层，理论上不应该有业务规则或逻辑，主要面向用例和流程相关的操作。

位于领域层之上，领域层包含多个聚合，所以它可以协调多个聚合的服务和领域对象完成服务编排和组合，协作完成业务操作。

应用层也是微服务之间交互的通道，它可以调用其它微服务的应用服务，完成微服务之间的服务组合和编排。

注意：

在设计和开发时，不要将本该放在领域层的业务逻辑放到应用层中实现。因为庞大的应用层会使领域模型失焦，时间一长你的微服务就会演化为传统的三层架构，业务逻辑会变得混乱。
	
应用服务是在应用层的，它负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，以粗粒度的服务通过 API 网关向前端发布。
	
应用服务还可以进行安全认证、权限校验、事务控制、发送或订阅领域事件等。
3.领域层

领域层的作用是实现企业核心业务逻辑，通过各种校验手段保证业务的正确性。

领域层主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。

领域层包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。

注意：

领域模型的业务逻辑主要是由实体和领域服务来实现的，其中实体会采用充血模型来实现所有与之相关的业务功能。
	
实体和领域服务在实现业务逻辑上不是同级的，当领域中的某些功能，单一实体（或者值对象）不能实现时，领域服务就会出马，它可以组合聚合内的多个实体（或者值对象），实现复杂的业务逻辑。
4.基础层

基础层是贯穿所有层的，它的作用就是为其它各层提供通用的技术和基础服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。比较常见的功能还是提供数据库持久化。

基础层包含基础服务，它采用依赖倒置设计，封装基础资源服务，实现应用层、领域层与基础层的解耦，降低外部资源变化对应用的影响。

5.从三层架构向 DDD 分层架构演进

DDD 分层架构中的要素其实和三层架构类似，只是在 DDD 分层架构中，这些要素被重新归类，重新划分了层，确定了层与层之间的交互规则和职责边界。



三层架构向 DDD 分层架构演进，主要发生在业务逻辑层和数据访问层。
	
DDD 分层架构在用户接口层引入了 DTO，给前端提供了更多的可使用数据和更高的展示灵活性。
	
DDD 分层架构对三层架构的业务逻辑层进行了更清晰的划分，改善了三层架构核心业务逻辑混乱，代码改动相互影响大的情况。
	
DDD 分层架构将业务逻辑层的服务拆分到了应用层和领域层。应用层快速响应前端的变化，领域层实现领域模型的能力。
	
在数据访问层和基础层之间：三层架构数据访问采用 DAO 方式；DDD 分层架构的数据库等基础资源访问，采用了仓储（Repository）设计模式，通过依赖倒置实现各层对基础资源的解耦。仓储又分为两部分：仓储接口和仓储实现。仓储接口放在领域层中，仓储实现放在基础层。原来三层架构通用的第三方工具包、驱动、Common、Utility、Config 等通用的公共的资源类统一放到了基础层。
（四）三种微服务架构模型的对比和分析



重点关注图中的红色线框，它们是非常重要的分界线，这三种架构里面都有，它的作用就是将核心业务逻辑与外部应用、基础资源进行隔离。
	
红色框内部主要实现核心业务逻辑，划分了应用层和领域层，来承担不同的业务逻辑。
	
领域层实现面向领域模型，实现领域模型的核心业务逻辑，属于原子模型，它需要保持领域模型和业务逻辑的稳定，对外提供稳定的细粒度的领域服务，所以它处于架构的核心位置。
	
应用层实现面向用户操作相关的用例和流程，对外提供粗粒度的 API 服务。它就像一个齿轮一样进行前台应用和领域层的适配，接收前台需求，随时做出响应和调整，尽量避免将前台需求传导到领域层。应用层作为配速齿轮则位于前台应用和领域层之间。
二、领域驱动设计分层架构与微服务代码模型

DDD 并没有给出标准的代码模型，不同的人可能会有不同理解。这里我们在使用的时候还是建议按照欧创新架构师总结的来进行适用，具体如下：

（一）代码模型总目录结构



根据 DDD 分层架构模型建立了标准的微服务代码模型，在代码模型里面，各代码对象各据其位、各司其职，共同协作完成微服务的业务逻辑。它包括用户接口层、应用层、领域层和基础层，分层架构各层的职责边界非常清晰，又能有条不紊地分层协作。

用户接口层：面向前端提供服务适配，面向资源层提供资源适配。这一层聚集了接口适配相关的功能。
	
应用层职责：实现服务组合和编排，适应业务流程快速变化的需求。这一层聚集了应用服务和事件相关的功能。
	
领域层：实现领域的核心业务逻辑。这一层聚集了领域模型的聚合、聚合根、实体、值对象、领域服务和事件等领域对象，以及它们组合所形成的业务能力。
	
基础层：贯穿所有层，为各层提供基础资源服务。这一层聚集了各种底层资源相关的服务和能力。
业务逻辑从领域层、应用层到用户接口层逐层封装和协作，对外提供灵活的服务，既实现了各层的分工，又实现了各层的协作。

1.微服务一级目录结构



微服务一级目录是按照 DDD 分层架构的分层职责来定义的。从下面这张图中，我们可以看到，在代码模型里分别为用户接口层、应用层、领域层和基础层，建立了 interfaces、application、domain 和 infrastructure 四个一级代码目录。

2.用户接口层目录结构、职能和代码形态

主要存放用户接口层与前端交互、展现数据相关的代码。前端应用通过这一层的接口，向应用服务获取展现所需的数据。这一层主要用来处理用户发送的 Restful 请求，解析用户输入的配置文件，并将数据传递给 Application 层。数据的组装、数据传输格式以及 Facade 接口等代码都会放在这一层目录里。

具体如下：



Assembler：实现 DTO 与领域对象之间的相互转换和数据交换。一般来说 Assembler 与 DTO 总是一同出现。
	
Dto：它是数据传输的载体，内部不存在任何业务逻辑，我们可以通过 DTO 把内部的领域对象与外界隔离。
	
Facade：提供较粗粒度的调用接口，将用户请求委派给一个或多个应用服务进行处理。
3.应用层目录结构、职能和代码形态

主要存放应用层服务组合和编排相关的代码。应用服务向下基于微服务内的领域服务或外部微服务的应用服务完成服务的编排和组合，向上为用户接口层提供各种应用数据展现支持服务。应用服务和事件等代码会放在这一层目录里。

具体如下：



Event（事件）：这层目录主要存放事件相关的代码。它包括两个子目录：publish 和 subscribe。前者主要存放事件发布相关代码，后者主要存放事件订阅相关代码（事件处理相关的核心业务逻辑在领域层实现）。为了实现事件的统一管理，建议你将微服务内所有事件的发布和订阅的处理都统一放到应用层，事件相关的核心业务逻辑实现放在领域层。通过应用层调用领域层服务，来实现完整的事件发布和订阅处理流程。
	
Service（应用服务）：这层的服务是应用服务。应用服务会对多个领域服务或外部应用服务进行封装、编排和组合，对外提供粗粒度的服务。应用服务主要实现服务组合和编排，是一段独立的业务逻辑。你可以将所有应用服务放在一个应用服务类里，也可以把一个应用服务设计为一个应用服务类，以防应用服务类代码量过大。
4.领域层目录结构、职能和代码形态

主要存放领域层核心业务逻辑相关的代码。领域层可以包含多个聚合代码包，它们共同实现领域模型的核心业务逻辑。聚合以及聚合内的实体、方法、领域服务和事件等代码会放在这一层目录里。

具体如下：



Aggregate（聚合）：它是聚合软件包的根目录，可以根据实际项目的聚合名称命名，比如权限聚合。在聚合内定义聚合根、实体和值对象以及领域服务之间的关系和边界。聚合内实现高内聚的业务逻辑，它的代码可以独立拆分为微服务。以聚合为单位的代码放在一个包里的主要目的是为了业务内聚，而更大的目的是为了以后微服务之间聚合的重组。聚合之间清晰的代码边界，可以让你轻松地实现以聚合为单位的微服务重组，在微服务架构演进中有着很重要的作用。
	
Entity（实体）：它存放聚合根、实体、值对象以及工厂模式（Factory）相关代码。实体类采用充血模型，同一实体相关的业务逻辑都在实体类代码中实现。跨实体的业务逻辑代码在领域服务中实现。
	
Event（事件）：它存放事件实体以及与事件活动相关的业务逻辑代码。
	
Service（领域服务）：它存放领域服务代码。一个领域服务是多个实体组合出来的一段业务逻辑。你可以将聚合内所有领域服务都放在一个领域服务类中，你也可以把每一个领域服务设计为一个类。如果领域服务内的业务逻辑相对复杂，建议将一个领域服务设计为一个领域服务类，避免由于所有领域服务代码都放在一个领域服务类中，而出现代码臃肿的问题。领域服务封装多个实体或方法后向上层提供应用服务调用。
	
Repository（仓储）：它存放所在聚合的查询或持久化领域对象的代码，通常包括仓储接口和仓储实现方法。为了方便聚合的拆分和组合，我们设定了一个原则：一个聚合对应一个仓储。（特别说明：按照 DDD 分层架构，仓储实现本应该属于基础层代码，但为了在微服务架构演进时，保证代码拆分和重组的便利性，把聚合仓储实现的代码放到了聚合包内。）
5.基础层层目录结构、职能和代码形态

主要存放基础资源服务相关的代码，为其它各层提供的通用技术能力、三方软件包、数据库服务、配置和基础资源服务的代码都会放在这一层目录里。

具体如下：



Config：主要存放配置相关代码。
	
Util：主要存放平台、开发框架、消息、数据库、缓存、文件、总线、网关、第三方类库、通用算法等基础代码，你可以为不同的资源类别建立不同的子目录。
（二）应用层的领域对象分析

应用层的主要领域对象是应用服务和事件的发布以及订阅。

在事件风暴或领域故事分析时，我们往往会根据用户或系统发起的命令，来设计服务或实体方法。为了响应这个命令，我们需要分析和记录：

在应用层和领域层分别会发生哪些业务行为；
	
各层分别需要设计哪些服务或者方法；
	
这些方法和服务的分层以及领域类型（比如实体方法、领域服务和应用服务等），它们之间的调用和组合的依赖关系。
在严格分层架构模式下，不允许服务的跨层调用，每个服务只能调用它的下一层服务。服务从下到上依次为：实体方法、领域服务和应用服务。建议采用服务逐层封装的方式，服务的封装和调用主要有以下几种方式：



1.实体方法的封装

实体方法是最底层的原子业务逻辑。

如果单一实体的方法需要被跨层调用，你可以将它封装成领域服务，这样封装的领域服务就可以被应用服务调用和编排了。
	
如果它还需要被用户接口层调用，需要将这个领域服务封装成应用服务。
经过逐层服务封装，实体方法就可以暴露给上面不同的层，实现跨层调用。

封装时服务前面的名字可以保持一致，你可以用 *DomainService 或 *AppService 后缀来区分领域服务或应用服务。

2.领域服务的组合和封装

领域服务会对多个实体和实体方法进行组合和编排，供应用服务调用。

如果它需要暴露给用户接口层，领域服务就需要封装成应用服务。

3.应用服务的组合和编排

应用服务会对多个领域服务进行组合和编排，暴露给用户接口层，供前端应用调用。

多个应用服务可能会对多个同样的领域服务重复进行同样业务逻辑的组合和编排。当出现这种情况时，就需要分析是不是领域服务可以整合了。可以将这几个不断重复组合的领域服务，合并到一个领域服务中实现，这样领域模型将会越来越精炼，更能适应业务的要求。

应用服务类放在应用层 Service 目录结构下。领域事件的发布和订阅类放在应用层 Event 目录结构下。

（三）领域层的领域对象分析

事件风暴结束时，领域模型聚合内一般会有：聚合、实体、命令和领域事件等领域对象。

在完成故事分析和微服务设计后，微服务的聚合内一般会有：聚合、聚合根、实体、值对象、领域事件、领域服务和仓储等领域对象。

1.设计实体

大多数情况下，领域模型的业务实体与微服务的数据库实体是一一对应的。

但某些领域模型的实体在微服务设计时，可能会被设计为多个数据实体，或者实体的某些属性被设计为值对象。

在分层架构里，实体采用充血模型，在实体类内实现实体的全部业务逻辑。这些不同的实体都有自己的方法和业务行为，比如地址实体有新增和修改地址的方法，银行账号实体有新增和修改银行账号的方法。

实体类放在领域层的 Entity 目录结构下。

2.找出聚合根

聚合根来源于领域模型，聚合根是一种特殊的实体，它有自己的属性和方法。聚合根可以实现聚合之间的对象引用，还可以引用聚合内的所有实体。

在个人客户聚合里，个人客户这个实体是聚合根，它负责管理地址、电话以及银行账号的生命周期。
	
个人客户聚合根通过工厂和仓储模式，实现聚合内地址、银行账号等实体和值对象数据的初始化和持久化。
聚合根类放在代码模型的 Entity 目录结构下。聚合根有自己的实现方法，比如生成客户编码，新增和修改客户信息等方法。

3.设计值对象

根据需要将某些实体的某些属性或属性集设计为值对象。值对象类放在代码模型的 Entity 目录结构下。

在个人客户聚合中，客户拥有客户证件类型，它是以枚举值的形式存在，所以将它设计为值对象。

有些领域对象可以设计为值对象，也可以设计为实体，我们需要根据具体情况来分析：

如果这个领域对象在其它聚合内维护生命周期，且在它依附的实体对象中只允许整体替换，我们就可以将它设计为值对象。
	
如果这个对象是多条且需要基于它做查询统计，建议将它设计为实体。
4.设计领域事件

如果领域模型中领域事件会触发下一步的业务操作，我们就需要设计领域事件。

首先确定领域事件发生在微服务内还是微服务之间。
	
然后设计事件实体对象，事件的发布和订阅机制，以及事件的处理机制。
	
判断是否需要引入事件总线或消息中间件。
领域事件实体和处理类放在领域层的 Event 目录结构下。领域事件的发布和订阅类建议放在应用层的 Event 目录结构下。

5.设计领域服务

如果一个业务动作或行为跨多个实体，我们就需要设计领域服务。

领域服务通过对多个实体和实体方法进行组合，完成核心业务逻辑。可以认为领域服务是位于实体方法之上和应用服务之下的一层业务逻辑。

按照严格分层架构层的依赖关系：

如果实体的方法需要暴露给应用层，它需要封装成领域服务后才可以被应用服务调用。
	
如果有的实体方法需要被前端应用调用，我们会将它封装成领域服务，然后再封装为应用服务。
领域服务类放在领域层的 Service 目录结构下。

6.设计仓储

每一个聚合都有一个仓储，仓储主要用来完成数据查询和持久化操作。

仓储包括仓储的接口和仓储实现，通过依赖倒置实现应用业务逻辑与数据库资源逻辑的解耦。

仓储代码放在领域层的 Repository 目录结构下。

（四）代码模型强调内容

第一点：聚合之间的代码边界一定要清晰。

聚合之间的服务调用和数据关联应该是尽可能的松耦合和低关联，聚合之间的服务调用应该通过上层的应用层组合实现调用，原则上不允许聚合之间直接调用领域服务。

这种松耦合的代码关联，在以后业务发展和需求变更时，可以很方便地实现业务功能和聚合代码的重组，在微服务架构演进中将会起到非常重要的作用。

第二点：你一定要有代码分层的概念。

写代码时一定要搞清楚代码的职责，将它放在职责对应的代码目录内。

应用层代码主要完成服务组合和编排，以及聚合之间的协作，它是很薄的一层，不应该有核心领域逻辑代码。

领域层是业务的核心，领域模型的核心逻辑代码一定要在领域层实现。

如果将核心领域逻辑代码放到应用层，你的基于 DDD 分层架构模型的微服务慢慢就会演变成传统的三层架构模型了。

三、正确理解微服务的边界

微服务设计的重点，就是看微服务设计是否能够支持架构长期、轻松的演进。

在事件风暴中，我们会梳理出业务过程中的用户操作、事件以及外部依赖关系等，根据这些要素梳理出实体等领域对象。

根据实体对象之间的业务关联性，将业务紧密相关的多个实体进行组合形成聚合，聚合之间是第一层边界。
	
根据业务及语义边界等因素将一个或者多个聚合划定在一个限界上下文内，形成领域模型，限界上下文之间的边界是第二层边界。
为了方便理解，我们将这些边界细分为：逻辑边界、物理边界和代码边界。

（一）逻辑边界

逻辑边界主要定义同一业务领域或应用内紧密关联的对象所组成的不同聚类的组合之间的边界。

微服务内聚合之间的边界就是逻辑边界。一般来说微服务会有一个以上的聚合，在开发过程中不同聚合的代码隔离在不同的聚合代码目录中。它是一个虚拟的边界，强调业务的内聚，可根据需要变成物理边界，也就是说聚合也可以独立为微服务。

微服务的架构演进并不是随心所欲的，需要遵循一定的规则，这个规则就是逻辑边界。微服务架构演进时，在业务端以聚合为单位进行业务能力的重组，在微服务端以聚合的代码目录为单位进行微服务代码的重组。

来看一个微服务实例，在下面这张图中，我们可以看到微服务里包含了两个聚合的业务逻辑，两个聚合分别内聚了各自不同的业务能力，聚合内的代码分别归到了不同的聚合目录下。



那随着业务的快速发展，如果某一个微服务遇到了高性能挑战，需要将部分业务能力独立出去，我们就可以以聚合为单位，将聚合代码拆分独立为一个新的微服务，这样就可以很容易地实现微服务的拆分。

另外，我们也可以对多个微服务内有相似功能的聚合进行功能和代码重组，组合为新的聚合和微服务，独立为通用微服务，有点做中台的感觉！

（二）物理边界

微服务之间的边界是物理边界。它强调微服务部署和运行的隔离，关注微服务的服务调用、容错和运行等。

物理边界主要从部署和运行的视角来定义微服务之间的边界。不同微服务部署位置和运行环境是相互物理隔离的，分别运行在不同的进程中。这种边界就是微服务之间的物理边界。

举例：



有些项目团队在将集中式单体应用拆分为微服务时，首先进行的往往不是建立领域模型，而只是按照业务功能将原来单体应用的一个软件包拆分成多个所谓的“微服务”软件包，而这些“微服务”内的代码仍然是集中式三层架构的模式，“微服务”内的代码高度耦合，逻辑边界不清晰，这里我们暂且称它为“小单体微服务”。

而随着新需求的提出和业务的发展，这些小单体微服务会慢慢膨胀起来。当有一天你发现这些膨胀了的微服务，有一部分业务功能需要拆分出去，或者部分功能需要与其它微服务进行重组时，你会发现原来这些看似清晰的微服务，不知不觉已经摇身一变，变成了臃肿油腻的大单体了，而这个大单体内的代码依然是高度耦合且边界不清的。

这种单体式微服务只定义了一个维度的边界，也就是微服务之间的物理边界，本质上还是单体架构模式。微服务设计时要考虑的不仅仅只有这一个边界，别忘了还要定义好微服务内的逻辑边界和代码边界，这样才能得到你想要的结果。

（三）代码边界

不同层或者聚合之间代码目录的边界是代码边界。它强调的是代码之间的隔离，方便架构演进时代码的重组。

代码边界主要用于微服务内的不同职能代码之间的隔离。

微服务开发过程中会根据代码模型建立相应的代码目录，实现不同功能代码的隔离。由于领域模型与代码模型的映射关系，代码边界直接体现出业务边界。

代码边界可以控制代码重组的影响范围，避免业务和服务之间的相互影响。

微服务如果需要进行功能重组，只需要以聚合代码为单位进行重组就可以了。

四、正确认识服务和数据在微服务各层的协作

（一）正确认识服务的协作

1. 服务的类型

按照分层架构设计出来的微服务，其内部有 Facade 服务、应用服务、领域服务和基础服务。之前都有提到，这里可以回忆一下！

2. 服务的调用（三类主要场景）

微服务的服务调用包括三类主要场景：微服务内跨层服务调用，微服务之间服务调用和领域事件驱动。




	
微服务内跨层服务调用
	
前端应用调用发布在 API 网关上的 Facade 服务，Facade 定向到应用服务。应用服务作为服务组织和编排者，它的服务调用有这样两种路径：

第一种是应用服务调用并组装领域服务。此时领域服务会组装实体和实体方法，实现核心领域逻辑。领域服务通过仓储服务获取持久化数据对象，完成实体数据初始化。
	
第二种是应用服务直接调用仓储服务。这种方式主要针对像缓存、文件等类型的基础层数据访问。这类数据主要是查询操作，没有太多的领域逻辑，不经过领域层，不涉及数据库持久化对象。
 


	
微服务之间的服务调用
	
微服务之间的应用服务可以直接访问，也可以通过 API 网关访问。

由于跨微服务操作，在进行数据新增和修改操作时，你需关注分布式事务，保证数据的一致性。


	
领域事件驱动
	
领域事件驱动包括微服务内和微服务之间的事件。

微服务内通过事件总线（EventBus）完成聚合之间的异步处理。
	
微服务之间通过消息中间件完成。异步化的领域事件驱动机制是一种间接的服务访问方式。
当应用服务业务逻辑处理完成后，如果发生领域事件，可调用事件发布服务，完成事件发布。

当接收到订阅的主题数据时，事件订阅服务会调用事件处理领域服务，完成进一步的业务操作。

3. 服务的封装与组合

微服务的服务是从领域层逐级向上封装、组合和暴露的。基本如下图体现：



（二）正确认识服务数据的协作

在 DDD 中有很多的数据对象，这些对象分布在不同的层里。它们在不同的阶段有不同的形态：

数据持久化对象 PO(Persistent Object)，与数据库结构一一映射，是数据持久化过程中的数据载体。
	
领域对象 DO（Domain Object），微服务运行时的实体，是核心业务的载体。
	
数据传输对象 DTO（Data Transfer Object），用于前端与应用层或者微服务之间的数据组装和传输，是应用之间数据传输的载体。
	
视图对象 VO（View Object），用于封装展示层指定页面或组件的数据。
微服务各层数据对象的职责和转换过程如下：



1.基础层数据协作

基础层的主要对象是 PO 对象。

我们需要先建立 DO 和 PO 的映射关系：

当 DO 数据需要持久化时，仓储服务会将 DO 转换为 PO 对象，完成数据库持久化操作。
	
当 DO 数据需要初始化时，仓储服务从数据库获取数据形成 PO 对象，并将 PO 转换为 DO，完成数据初始化。
大多数情况下 PO 和 DO 是一一对应的。但也有 DO 和 PO 多对多的情况，在 DO 和 PO 数据转换时，需要进行数据重组。

2.领域层数据协作

领域层的主要对象是 DO 对象。

DO 是实体和值对象的数据和业务行为载体，承载着基础的核心业务逻辑。

通过 DO 和 PO 转换，我们可以完成数据持久化和初始化。

3.应用层数据协作

应用层的主要对象是 DO 对象。

如果需要调用其它微服务的应用服务，DO 会转换为 DTO，完成跨微服务的数据组装和传输。

用户接口层先完成 DTO 到 DO 的转换，然后应用服务接收 DO 进行业务处理。如果 DTO 与 DO 是一对多的关系，这时就需要进行 DO 数据重组。

4.用户接口层数据协作

用户接口层会完成 DO 和 DTO 的互转，完成微服务与前端应用数据交互及转换。

Facade 服务会对多个 DO 对象进行组装，转换为 DTO 对象，向前端应用完成数据转换和传输。

5.前端应用数据协作

前端应用主要是 VO 对象。

展现层使用 VO 进行界面展示，通过用户接口层与应用层采用 DTO 对象进行数据交互。

 

参考书籍、文献和资料

1.极客时间课程《DDD实战》，欧创新，2019.

2.郑天民. 微服务设计原理与架构. 北京：人民邮电出版社，2018.

3.陈超、秦金卫、张逸等. 高可用可伸缩微服务架构. 电子工业出版社. 2019.

4.Eric Evans. 领域驱动设计-软件核心复杂性应对之道。 人民邮电出版社. 2018.

架构


架构是被CIO界用烂的词（这帮一瓶子醋不满半瓶子醋晃悠还爱指点江山的家伙）。我来说说我们做企业应用软件的人眼中的架构。


一、业务模型架构


流程管理方法论：按企业组织、岗位、职责、流程、标准输入表单和输出查询\报表、绩效考核指标


战略地图\平衡计分卡方法论：按战略管控、计划PDCA管控、财务管控、经营考核指标体系


二、应用架构


1、部署架构：物理部署架构、软件逻辑部署架构

2、功能模型和业务模型的映射关系

3、功能分类与功能之间的关系：收银计费交易类功能、过程记录类功能、过程管控类功能、查询统计类功能

4、本次版本的功能与过去版本的功能之间的关系、分离、耦合连接


三、集成架构


1、集成门户


2、组织集成、权限集成


3、主数据集成、商业智能数据集成


4、业务流程集成、审批流程集成


5、消息集成


6、知识管理


四、服务工具集


1、建模工具集：如
组织建模工具、权限管理工具
功能建模工具、业务基础参数配置工具
UI建模工具、计算公式规则工具、编号规则配置工具
流程建模工具
报表建模工具
预警规则建模工具、消息模板

2、实施工具集：如
高性能、高安全、高灾备、高扩展安装部署工具
初始化工具
主数据清洗工具、导入工具、数据质量检查工具
切换上线工具

3、服务工具集：如
性能监控、安全监控、配置变更监控、日志异常监控
性能检查、安全检查、性能优化、
数据检查、数据修复、数据备份、数据同步、数据复制、数据恢复
系统迁移、系统扩展、系统升级


五、基础技术引擎与类库框架


1、安全、路由、字符集、缓存、日志、异常、事务、并发、复制同步、sharding、查询分离


六、代码架构

1、功能与代码的映射关系

2、代码层与层之间的调用关系

3、功能与功能之间代码接口、系统与系统之间代码接口

4、产品代码和项目代码的分离、耦合

5、本次版本的产品代码和过去版本的产品代码的分离、耦合


七、数据架构


1、业务实体关系、业务实体与数据库概念设计映射


2、数据库概念设计与特定数据存储映射

	
 共享平台逻辑架构设计
	


如上图所示为本次共享资源平台逻辑架构图，上图整体展现说明包括以下几个方面：

1 应用系统建设

本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发，从而建立行业的全面的应用系统架构群。整体应用系统通过SOA面向服务管理架构模式实现应用组件的有效整合，完成应用系统的统一化管理与维护。

2 应用资源采集

整体应用系统资源统一分为两类，具体包括结构化资源和非机构化资源。本次项目就要实现对这两类资源的有效采集和管理。对于非结构化资源，我们将通过相应的资源采集工具完成数据的统一管理与维护。对于结构化资源，我们将通过全面的接口管理体系进行相应资源采集模板的搭建，采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。

3 数据分析与展现

采集完成的数据将通过有效的资源分析管理机制实现资源的有效管理与展现，具体包括了对资源的查询、分析、统计、汇总、报表、预测、决策等功能模块的搭建。

4 数据的应用

最终数据将通过内外网门户对外进行发布，相关人员包括局内各个部门人员、区各委办局、用人单位以及广大公众将可以通过不同的权限登录不同门户进行相关资源的查询，从而有效提升了我局整体应用服务质量。

综上，我们对本次项目整体逻辑架构进行了有效的构建，下面我们将从技术角度对相关架构进行描述。

 


	
 技术架构设计
	


如上图对本次项目整体技术架构进行了设计，从上图我们可以看出，本次项目整体建设内容应当包含了相关体系架构的搭建、应用功能完善可开发、应用资源全面共享与管理。下面我们将分别进行说明。


	
 整体架构设计
	
上述两节，我们对共享平台整体逻辑架构以及项目搭建整体技术架构进行了分别的设计说明，通过上述设计，我们对整体项目的架构图进行了归纳如下：



综上，我们对整体应用系统架构图进行了设计，下面我们将分别进行说明。


	

		
应用层级说明
		
	
整体应用系统架构设计分为五个基础层级，通过有效的层级结构的划分可以全面展现整体应用系统的设计思路。

基础层

基础层建设是项目搭建的基础保障，具体内容包含了网络系统的建设、机房建设、多媒体设备建设、存储设备建设以及安全设备建设等，通过全面的基础设置的搭建，为整体应用系统的全面建设良好的基础。

应用数据层

应用数据层是整体项目的数据资源的保障，本次项目建设要求实现全面的资源共享平台的搭建，所以对于应用数据层的有效设计规划对于本次项目的建设有着非常重要的作用。

从整体结构上划分，我们将本次项目建设数据资源分为基础的结构型资源和非结构型资源，对于非结构型资源我们将通过基础内容管理平台进行有效的管理维护，从而供用户有效的查询浏览；对于结构型数据，我们进行了有效的分类，具体包括政务公开资源库、办公资源库、业务经办资源库、分析决策资源库、内部管理资源库以及公共服务资源库。通过对资源库的有效分类，建立完善的元数据管理规范，从而更加合理有效的实现资源的共享机制。

应用支撑层

应用支撑层是整体应用系统建设的基础保障，根据本次招标文件相关需求，我们进行了相关面向服务体系架构的设计，通过统一的企业级总线服务实现相关引用组件包括工作流、表单、统一管理、资源共享等应用组件进行有效的整合和管理，各个应用系统的建设可以右下基于基础支撑组件的应用，快速搭建相关功能模块。

由此可见，应用支撑层的建设是整体架构设计的核心部分，其关系到本次项目的顺利搭建以及今后区劳动局信息化的发展。

应用管理层

在3.3.3图中的设计中，应用管理层有效的承接了我局原有应用系统分类标准，将实际应用系统分成了八个应用体系，在实际应用系统的建设中，我们将全面传承原有应用分类标准规范的基础上实现有效的多维的应用资源分类方法，不仅如此，整体应用系统也可以通过多维的管理模式进行相关操作管理，如按照业务将应用系统进行划分，包括劳动管理和保险管理等。

应用管理层是实际应用系统的建设层，通过应用支撑层相关整合机制的建立，我们将实现应用管理层相关应用系统的有效整合，通过统一化的管理体系，全面提升我局应用系统管理效率，提升服务质量。

展现层

整体应用功能将通过门户方式进行展现，架构分别设计了内网门户和外网门户，不同的应用人员通过登录可以实现相关系统的应用和资源的浏览查询操作。

3.2准体系规范说明
大型的应用工程项目的建设必须遵照严格的标准体系建设规范，根据本次项目实际需求，我们通过三个规范体系对项目进行合理的保障，具体包括了安全标准管理系统、标准规范体系以及运行管理体系。

通过相关标准的制定、安全架构的保障以及管理规范的建设可以保障整体应用系统的设计、搭建、运维等全流程性工作。

3.3应用用户设计
通过分析，我们将整体应用系统面向人群分为四类，具体包括广大公众、区内委办局、局内相关部门以及用人单位，不同对象通过访问不同门户可以进行全面的服务保障。

3.4系统建设总结
在3.3.3图中对本次项目整体应用系统建设需求同样也进行了归纳，项目整体分为三个主体建设，即：共享信息平台的搭建、原有应用系统的改造以及新的应用系统的搭建。

共享信息平台的建设旨在全面整合相关应用系统资源，实现有效的浏览、查询检索机制，整体数据通过规范化的元数据管理机制，实现有效的梳理存储，为今后资源的整合奠定基础。不仅如此，在实际项目建设中还将引入商业智能应用模块，实现对共享资源的智能化分析，从而为决策预警等提供有力依据。

原有业务系统改造则是实现原有应用系统相关流程等的优化配置，并通过有效的数据梳理改造为信息资源的共享奠定良好的基础。本次项目中需要改造系统包括：政务公开系统、办公自动化系统、公众服务系统以及综合管理系统。

新的业务系统的建设则是要全面提升现阶段我局整体办公效率，继续加强信息化建设，通过更加全面合理的应用系统的建设，提升我局整体服务水平。本次项目需要建设系统包括：业务经办系统、社会保险系统、土地储备系统、企业监督系统、劳动监察系统、劳动关系与仲裁系统、就业和失业管理系统以及综合管理系统。

3.5应用接口管理
本次项目建设还涉及到整体应用系统与外部相关系统接口的管理，实际应用接口包括与税务接口、与财政部门接口、与民政部门接口、与基层单位接口与公安部门接口以及与其他部门的接口。

通过有效的接口管理机制，实现资源的互联互通，从而更加有效的提升我局无纸化办公机制，全面加强我局整体工作效率。


	
系统整体逻辑架构
	
规划一个成熟先进的北京市卫生人才交流服务中心网站平台系统框架是一切技术工作的先决条件，是奠定系统性能的基础，是至关重要的。

因此，本项目建设应首先考虑设计和建立一个统一的北京市卫生人才交流服务中心门户网站系统技术体系，能够支持政府信息资源的整合、管理及门户网站群的建设，提供统一的内容管理、资源整合、安全管理构架，并提供对应用服务的统一调度和管理，同时，系统体系结构应分层组织，系统功能模块化，系统集成松耦合，方便业务应用的修改、重用和部署，满足系统未来弹性扩展的要求。

系统逻辑框架如下图所示。



整体系统包括三个体系一个平台进行全面保障，其中三个体系包括：

运行管理体系；
	
标准规范体系；
	
安全保障体系；
具体平台根据新闻局实际需求建设网站群支撑管理平台，平台保障了相关招标文件中的采集管理、内容管理、统计管理、安全管理等功能需求，对于整体应用平台的支撑则通过中科软多年门户建设经验总结完成的相关应用组件包括工作流管理、元数据管理、电子表单等进行保障。


	

		
 各主要组成部分概要描述
		
	
	
数据层
对结构化数据和非结构化数据进行调度和存储。结构化数据包括：XML 和DBMS。非结构化数据包括：文本文件、音视频文件、office 系列文件、图形图像文件及ZIP、PDF、SWF等其他格式文件等，在数据接口上支持WebService 模块化组件。

支撑层
支撑层通过应用服务器，提供对系统应用层强大的支持，包括:电子表单、工作流、元数据管理、安全审计等功能。并通过WEBSERVICE接口服务支持外部资源对内容管理基础数据以及内容管理对外部数据资源的应用数据集成。

应用层
应用层是政府门户网站群非常重要的组成部分，是对信息处理的重要环节，按功能的不同可以分为：信息发布管理、网站群管理、系统管理、外挂组件管理、交互功能、多媒体信息管理、内容聚合:RSS等。

展现层
政府门户网站群的最终表现是一组具有相同标准和相同规范体系的网站群体系。它涵盖主站、各级子网站、各类专题子网站等，同时系统为应用层的不同应用提供信息资源的不同表现形式，包括有Web、RSS等。

接入层
实现客户通过浏览器来访问表现层以获取信息资源。


	
 系统技术架构
	
系统技术架构框架如图所示。




	
总体架构设计
	


应用系统总体架构图

如上图所示，本项目将采用数据与应用大集中的架构，即国际收支平衡管理管理信息系统只部署在国家外汇管理局，相关数据也集中存储在总局的国际收支平衡整合库中。整个系统采用B/S的结构，在进行数据清洗、转换，即ETL的时候会采用C/S结构，整个架构主要包括如下内容：

1、构建应用支撑平台，提供统一的人员、组织机构和权限管理，提供支持各种复杂业务系统的开发和组装框架，实现单点登录和目录服务，并提供对应用系统的运行监控，数据的备份恢复等功能。

国际收支平衡管理信息系统的各个子系统以及外汇局应用支撑平台门户都是基于应用支撑平台开发、组装和运行的。

2、数据整合与交换系统是整个国际收支平衡管理信息系统的基础，负责将从外汇局内部（主要是现有的业务系统或者业务数据）和外汇局外部（主要是共建部委的共享数据）的相关外汇数据采集、清洗、转换，并通过数据传输通道汇总至统一的国际收支信息的整合数据库中。

各分支局数据通过数据传输通道上传到国家外汇管理局，由数据整合和交换系统接收并处理数据，最终也汇总至总局的整合数据库中。

数据交换将以成熟、稳定的第三方产品为基础进行设计和开发。

3、开发新版国际收支网上申报系统，实现涉外收入申报业务网上受理，方便企业申报业务；建立与银行系统的接口，满足与银行的数据交换；方便银行的查询和审核操作。

网上申报数据将统一存储至网上申报数据库，并通过数据整合与交换系统与国际收支统计监测系统进行数据集成，同时申报数据最终汇总至总局的整合数据库中。

网上申报系统将与外汇局的“一站式”网上服务平台集成，申报主体和银行将通过服务平台登录系统，进行申报、审核、查询统计等操作。

外汇局人员也可通过服务平台或者外汇局的应用支撑平台门户登录系统，进行对申报数据的核查、查询统计操作。

4、在数据整合与交换系统上建设统计分析系统，根据基础指标和统计分析指标将整合数据库中的信息动态生成各类统计分析报表（如国际收支平衡表、国际投资头寸表、结售汇统计报表等）。

统计分析系统将利用数据仓库和多维联机在线分析技术，在对国际收支平衡状况的需求分析的基础上，提供面向主题的多种分析模型和分析方法，从多个角度分析国际收支平衡的状况和存在问题。统计分析结果将存储至外汇局数据仓库系统，为决策支持系统提供数据支撑，并可以通过BI工具在外汇局应用支撑平台门户进行展现。此外，统计报表信息通过数据整合与交换平台与金宏工程其他共建部委进行“共享”。

5、在统计分析系统和总局数据仓库的基础上建设决策支持系统，通过基础指标，统计分析指标和统计分析系统产生的结果，借助OLAP分析模型工具，产生决策支持信息和预警信息，进行经济分析和预警，辅助外汇管理政策的制定。

各类统计分析模型、预警模型将统一存放到“模型库”中，方便分析人员使用。此外还提供一套机制建设“知识库”，存储有关外汇管理的各类信息。

（2）－（4）这几个系统在支撑平台的数据整合与交换基础上提供统一的数据交换接口，同时支持以XML作为统一的数据接口格式。

6、建设外汇局应用支撑平台门户，通过门户对所有的系统进行统一管理，并且将统计分析、决策支持的结果和其他应用软件的功能模块通过信息集成门户提供给外汇局的领导、业务人员使用。

外汇局应用支撑平台门户就是建设在应用支撑平台门户基础上。

7、国际收支平衡管理系统与金宏共享平台、国际收支平衡共享数据库物理隔离，国际收支平衡管理系统中的数据通过涉密网和业务网之间的数据交换系统交换到金宏内网上的国际收支平衡共享数据库中，向共建部委提供数据服务。从共建部委获得的数据也通过涉密网和业务网交换系统，进入数据整合与交换系统中。


	
系统架构
	


国际收支网上申报系统技术架构图

企业用户可以通过“一站式”信息服务门户访问国际收支网上申报系统，完成涉外收支业务的申报，申报信息由数据管理模块通过特定的数据接口交换到银行业务系统，在银行业务系统进行审核。审核过后的结果信息再经过数据管理模块交换到网上申报系统供企业用户查询。

企业用户需要在银行业务系统完成账户开户，定时由银行业务系统交换到网上申报系统供企业用户登录。


	
系统架构
	


统计分析系统技术架构图

1、统计分析系统的数据来源于数据仓库，通过条件查询模块从数据仓库得到满足用户的基础数据，由数据统计模块来对这部分基础数据进行汇总统计；

2、汇总统计的数据根据外汇局用户的需要可以由报表定制模块利用原有的报表工具实现对国际收支平衡表、国际投资头寸表、结售汇统计报表、外债余额简表的设计以及利用Cognos的BI工具完成展现以及经过OLAP分析转化成多维数据；

3、针对预先设计好的数据模型以及辅助模型管理模块来产生分析结果，供外汇局用户制定决策。


	
系统架构
	


决策支持系统技术架构图

1、决策支持系统利用从数据仓库获得的基础数据完成报表和查询，生成日、月、季报表供外汇局用户查询浏览；

2、通过ASL规则引擎对基础数据进行分析，以风险模型为依据生成分析报告；

3、利用数据挖掘模型对基础数据进行处理得到模型数据，与ASL分析信息共同生成分析报告，供外汇局用户来进行营运监管的管理；

4、“知识库”的信息同时也提供给营运监管模块来进行运作。


	
总体架构
	


国资委国有资产监督管理系统总体架构图

国资委国有资产监督管理系统的总体框架主要包含六个层次，即基础平台层、数据资源管理层、应用支撑层、业务实现层、门户展现层、终端接入层。

1．基础平台层：国资委IT基础平台主要包括网络系统、主机、存储系统、安全系统、配套的软件等。网络系统分为业务内网、业务外网和互联网。业务内网与业务外网物理隔离，互联网与业务外网通过防火墙配置实现逻辑隔离。

2．数据资源管理层：数据资源管理层主要由数据库组成，其中结构化数据库主要包括管人、管事、管资产、纪检监督业务数据库、共享数据库、基础数据库、原有系统数据库及其它信息资源库等。非结构数据库主要是由一些文件型的数据构成。信息资源库主要是应用系统的数据库，它是业务应用信息系统的组成部分和数据中心的基础。

3．应用支撑层：应用支撑层主要包括应用开发平台 （基础数据管理、报表管理、工作流管理、表单工具、门户引擎、规则引擎、工作流引擎、用户权限管理、目录服务、内容管理、接口管理、预警平台）和中间件（应用服务器、消息中间件、WEB服务器）。通过建设应用支撑平台，实现界面集成、应用集成、数据集成及流程集成，通过四个集成来达到国资委所有系统的集成效果。

4．业务实现层：主要包括四大核心业务应用系统和数据中心。

国资监管应用系统主要包括企业国有资产产权登记子系统、上市公司国有股权监督管理子系统、企业国有产权交易监督管理子系统、企业财务状况监督子系统设计、中央企业财务绩效评价子系统、中央企业财务预决算管理子系统、企业国有资产统计评价子系统、企业财务信息查询分析子系统、中央企业人员管理子系统、中央企业业绩考核子系统、中央企业重大投资管理子系统、中央企业经济运行监督子系统、纪检监察管理子系统等。

国有资产数据中心：主要包括元数据注册器、信息资源数据库、信息资源目录体系、信息资源交换体系等。国有资产信息资源库是数据中心的基础，为国资委业务监管提供数据支持，包括企业基本信息数据、企业绩效评价数据、企业人员管理数据、企业财务数据、国有产权数据、资产统计数据、企业重组与规划投资数据、纪检监察数据、政策法规文献数据和其他业务数据十大类。作为统一信息资源平台，国有资产信息资源库对国资委各类共享数据提供统一的存储和管理，是国资委委内各厅局之间以及与其它政府机关之间进行数据交换和共享的基础平台，为各类业务的开展提供完整、统一和准确的数据支持。

5．门户展现层：门户展现层主要由国资委数据采集门户构成、互联网门户、业务内网门户、业务外网门户组成。

6．终端接入层：中央企业、地方国资委、上市企业（含国有股）、其它部门及公众通过统一的身份认证、权限管理登录数据采集门户、国资委业务外网门户、国资委互联网，并实现统一的入口、出口和单点登录。

其中，中央企业、地方国资委、上市企业（含国有股）通过在线填报或离线填报（利用数据采集终端）的方式在数据采集门户上进行数据填报，数据采集门户及业务外网与内网物理隔离，通过应用支撑平台提供的数据交换组件实现内、外网的数据传输和交换。其它部门（包括金宏工程相关部门）也是通过应用支撑平台提供的数据交换组件实现内、外网的数据传输和交换。社会公众登录国资委互联网网站进行国资监管信息查询和交互。

除此之外，贯穿着六个层次的还有国资委信息安全保障体系、项目实施与运维管理，和相关的标准体系和管理规范。


	
系统逻辑结构
	
国资监管信息系统主要作用体现为国资监管业务服务。一期工程建设6大应用系统，形成10个信息资源库。其总体逻辑结构图如下：

图5-1总体逻辑结构图

通过四大业务系统（共计13个子系统）覆盖国资委管资产、管人、管事、资产监督的四大业务。

其业务核心就是实现国有经济布局以及国有资产的增值保值。

实现国有经济布局，具体是通过产权登记系统，掌握所有国有股权的分布情况。通过上市公司国有股权交易监督和其他企业国有股权交易监督系统，对国有股权的交易进行监控，随时了解国有经济的布局情况，并加以控制。通过资产统计、企业财务监督、中央企业预决算管理，等3个系统，全面获得企业的实际财务资产情况。

另外通过中央企业经济运行管理系统，掌握中央企业的经济运行情况以及行业经济运行分析，从而对中央企业重大投资进行管理和监控，确保了解国有经济布局的运行情况和进行调整。

实现国有资产的增值保值，具体措施是通过管人来实现，通过中央企业人员管理系统，后备、任命、管理企业管理者。通过企业绩效考核系统来评价、更换人员，来实现国有资产的增值保值。但不是简单的通过管人来实现国有资产增值保值，任命、考核，需要从资产管理、资产监督、企业运行情况等三个方面不断地获取信息，对管理者进行监督和引导，即使发现问题，确保国有资产的增值保值。

通过13个业务应用系统覆盖四大业务职能，为解决目前监管业务中信息采集的问题、信息沟通的问题，需要建设13个业务应用系统统一的数据采集系统、信息发布系统。

针对13个业务应用，形成了10大国有资产信息资源库，包括监管企业方面获得的6种信息：

企业基本信息
	
企业产权信息
	
企业财务信息
	
企业人员信息
	
企业重组与规划投资信息
	
其他业务信息
以及国资委监管产生的4种信息：

政策法规信息
	
国有资产统计信息
	
企业业绩考核信息
	
纪检监察信息
	
系统体系结构
	
本项目总体技术框架建立要遵循“整合资源，信息共享”、“统一架构，业务协同”的原则，应用系统采用多层架构，以信息资源库和公共服务为基础进行开发，实现资源和服务的共享，实现业务层和展现层的分离。总体技术框架如下图所示：



图5-2 国资委国有资产监督管理系统总体技术框架

总体框架主要包含六个层次：

国资委IT基础设施：主要包括网络、服务器、存储系统、配套的系统软件、数据库和机房等。网络系统为内、外网物理隔离的双网结构。IT基础设施是国资委国有资产监督管理系统的基础平台。

国有资产数据中心：主要包括元数据注册器、信息资源数据库、信息资源目录体系、信息资源交换体系等。国有资产信息资源库是数据中心的基础，为国资委业务监管提供数据支持，包括企业基本信息数据、企业绩效评价数据、企业人员管理数据、企业财务数据、国有产权数据、资产统计数据、企业重组与规划投资数据、纪检监察数据、政策法规文献数据和其他业务数据十大类。作为统一信息资源平台，国有资产信息资源库对国资委各类共享数据提供统一的存储和管理，是国资委委内各厅局之间以及与其它政府机关之间进行数据交换和共享的基础平台，为各类业务的开展提供完整、统一和准确的数据支持。

国资委应用系统支撑平台：主要包括由表单工具、系统集成组件、内容管理工具、工作流组件、消息交换工具、应用中间件、统一用户管理和其他组件工具构成的应用支撑平台，从整合、协同、管理和服务四个方面对业务系统的开发、部署和运行进行支持。

国有资产监督管理业务应用信息系统：主要包括搭建在应用支撑平台上的基础应用组件、通过基础应用组件组合成的企业国有资产产权登记子系统、上市公司国有股权监督管理子系统、企业国有产权交易监督管理子系统、企业财务状况监督子系统设计、中央企业财务绩效评价子系统、中央企业财务预决算管理子系统、企业国有资产统计评价子系统、企业财务信息查询分析子系统、中央企业人员管理子系统、中央企业业绩考核子系统、中央企业重大投资管理子系统、中央企业经济运行监督子系统、纪检监察管理子系统。

应用数据库：主要是应用系统的数据库，是业务应用信息系统的组成部分。

国资委信息发布系统：主要包括国资委内网消息发布、外网消息发布和互联网消息发布。

除此之外，贯穿着六个层次的还有国资委信息安全保障体系、技术支持与运行维护体系。同时，国资委信息化相关的标准、规范、政策、法规也将在“国有资产监督管理系统”项目建设中必须加以重视，并积极推进。

架构设计学习思维导图: 架构设计系列主要的ADM（架构开发方法）主要基于TOGAF9或者TOGAF9.1来论述。这是个人学习实践和总结笔记，专注并不断积累和更新，努力精进自己。个人拙见,仅供参考。
1、 架构概述：了解架构基础知识：架构定义、分类、级别、应用架构演进、架构是否合理、架构误区等。
     《谈谈架构》
2、 原则模式：了解架构模式和设计原则。

     《架构设计原则》

      《架构模式》
3、 瀑布模式：根据瀑布开发模式，从前期的架构愿景->到架构需求分析->架构设计

      《架构愿景分析》

      《架构需求分析》

      《如何设计一个架构》
4、 架构三高:架构战术设计主要关注点：高可用、高性能、高效服务治理或者高并发

     《高可用架构设计》

     《高性能设计》

     《分布式服务治理》
5、 具体知识点：架构实施知识点,框架、组件、限流、容错等知识。

     《分布式链路跟踪》

     《分布式链路跟踪:Zipkin实践》

     《分布式链路跟踪:skywalking实践》

     《我们自研log2跟踪组件》




一、架构是什么

      在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前，我们先讨论架构的概念定义, 因为概念是人认识这个世界的基础和用来沟通的手段，如果对架构概念理解不一样，那沟通起来自然不顺畅。

     Linux有架构，MySQL有架构，JVM也有架构，使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构，应该关注哪一个？想要清楚以上问题需要梳理几个有关系又相似的概念：系统与子系统、模块与组建、框架与架构:  

一、系统与子系统

系统：泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能独立完成的工作能力的群体。

子系统：也是由一群关联的个体组成的系统，多半是在更大的系统中的一部分。

二、模块与组件

都是系统的组成部分，从不同角度拆分系统而已。模块是逻辑单元，组件是物理单元。

模块就是从逻辑上将系统分解， 即分而治之， 将复杂问题简单化。模块的粒度可大可小， 可以是系统，几个子系统、某个服务，函数， 类，方法、 功能块等等。

组件可以包括应用服务、数据库、网络、物理机、还可以包括MQ、容器、Nginx等技术组件。

三、框架与架构

框架是组件实现的规范，例如：MVC、MVP、MVVM等，是提供基础功能的产品，例如开源框架：Ruby on Rails、Spring、Laravel、Django等，这是可以拿来直接使用或者在此基础上二次开发。

框架是规范，架构是结构。

在TOGAF9是这么定义：一个系统基本的构件(子系统, 模块, 组件)，体现在它的各个构件、构件间的相互关系、构件与环境间的关系，以及对系统设计和演进进行治理的原则中。两种含义：

(1)、一个系统的形式化描述，或指导系统实现的构件级的详细计划。

(2)、一组构件的结构、构件间的相互关系、以及对这些构件的设计和随时间演进的过程进行治理的一些原则和指导策略

我在这重新定义架构：软件架构指软件系统顶层结构设计。

架构是经过系统性地思考, 权衡利弊之后在现有资源约束下的最合理决策, 最终明确的系统骨架: 包括子系统, 模块, 组件. 以及他们之间协作关系, 约束规范, 指导原则.  并由它来指导团队中的每个人思想层面上的一致。

涉及四方面：

1、系统性思考的合理决策：比如技术选型、解决方案、成本评估、性价比评估等等。

2、明确的系统骨架：明确系统有哪些部分组成。

3、系统协作关系：各个组成部分如何协作来实现业务请求。

4、约束规范和指导原则：保证系统有序，高效、稳定运行，包括规范、原则、流程等内容。

 

    

二、架构设计目的

      如果没有架构设计，说明你的系统不够复杂。随着业务的增长，系统由单体应用渐进演化为分布式和微服务化。系统整体的复杂性越来越高，技术团队可能从一个团队变成多个专业化团队。假如没有架构设计，系统定会是一个无序失控的状态，带来的问题：

      1、应用服务的边界不是很清晰：到底该怎么拆分没有一个明确的原则，研发人员为了所谓微服务化而拆分，而不是从当前业务考虑。我们系统出现过类似的情况：一个简单项目拆分成8个子服务，问他为什么这么拆分，说微服务化是为了应对以后扩展方便。结果这个项目从2017年到现在都没有再修改过，接手人宁愿新开发一个项目也不愿重构。

      2、应用服务层次不清晰：导致服务依赖出现网状依赖结构。

      3、系统应用服务跟踪问题：由于微服务化后，服务出现问题后，你很难快速的定位问题。这是我们踩过不少坑，我们使用dubbo服务化，系统一旦出现问题，一推人手忙脚乱。

      4、系统服务监控问题：由于研发人员基本没有服务监控意识，都是出现问题后再想办法如何添加服务监控接口。

       5、技术体系失控问题：不同的开发团队使用不同的技术栈或者组件，造成公司内部的技术架构失控。甚至研发人员为追求时髦新潮技术，拿应用项目来试验新技术。

       。。。。。。  能列举出来还有多各种各样问题。

 

      架构设计的目的是为了解决系统复杂性带来的问题，其本质就是对系统进行有序化地重构以致符合当前业务的发展，并可以快速扩展。从上面架构的定义，也知道架构设计的作用涉及四方面：1、系统性思考的合理决策。2、明确的系统骨架。3、系统协作关系。4、约束规范和指导原则。

架构师通过理解业务，全局把控，选择合适技术，解决关键问题、指导研发落地实施，促进业务发展，提高效率。


 那什么样的系统要考虑做架构设计?  技术不会平白无故的出和自驱动发展起来，而架构的发展和需求是基于业务的驱动。

 需求相对复杂.
	
 非功能性需求在整个系统占据重要位置.
	
 系统生命周期长,有扩展性需求.
	
 系统基于组件或者集成的需要.
	
 业务流程再造的需要.


 

三、架构分类

RUP4+1架构视图


1995年，Philippe Kruchten在《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文，引起了业界的极大关注，并最终被RUP采纳。即RUP4+1架构方法。该方法主要采用用例驱动，在软件生命周期的各个阶段对软件进行建模,从不同视角对系统进行解读，从而形成统一软件过程架构描述.

该方法的不同架构视图承载不同的架构设计决策，支持不同的目标和用途：

逻辑视图：用于描述系统软件功能拆解后的组件关系,组件约束和边界,反映系统整体组成与系统如何构建的过程。关注功能和逻辑层。

开发视图：描述系统的模块划分和组成,以及细化到内部包的组成设计,服务于开发人员,反映系统开发实施过程。

物理视图：描述软件如何映射到硬件，反映系统在分布方面的设计，系统的组件是如何部署到一组可计算机器节点上,用于指导软件系统的部署实施过程。

处理流程视图：用于描述系统软件组件之间的通信时序,数据的输入输出,反映系统的功能流程与数据流程,通常由时序图和流程图表示。关注进程、线程、对象等运行时概念以及相关的并发、同步、通信等问题。

运用4+1视图方法：针对不同需求进行架构设计




TOGAF9架构分类

TOGAF9来对架构分类：



由于不同架构方法论，定义的架构分类也不同，RUP4+1架构方法主要是以架构生命周期为视角进行描述，而TOGAF9按架构涉及内容维度来描述。因此我结合两者细分为业务架构、应用架构、数据架构、技术架构, 代码架构, 部署架构。

     

     业务架构是战略，应用架构是战术，技术架构是装备。其中应用架构承上启下，一方面承接业务架构的落地，另一方面影响技术选型。 熟悉业务，形成业务架构，根据业务架构，做出相应的应用架构，最后技术架构落地实施。

1、业务架构（俯视架构）

      包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。

       没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑，任何不基于业务做异想天开的架构都是耍流氓。

       所有问题的前提要搞清楚我们今天面临的业务量有多大，增长走势是什么样，而且解决高并发的过程，一定是一个循序渐进逐步的过程。 合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。

看看京东业务架构（网上分享图）   

     

2、应用架构（剖面架构，也叫逻辑架构图）：

硬件到应用的抽象，包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。

类似：



应用架构：应用作为独立可部署的单元，为系统划分了明确的边界，深刻影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。

应用架构图关键有2点：

1、职责划分:   明确应用（各个逻辑模块或者子系统）边界

    1）逻辑分层

    2）子系统、模块定义。

    3）关键类。
2、职责之间的协作：

   1）接口协议：应用对外输出的接口。

   2）协作关系：应用之间的调用关系。

    应用分层有两种方式：

    一种是水平分（横向），按照功能处理顺序划分应用，比如把系统分为web前端/中间服务/后台任务，这是面向业务深度的划分。

    另一种是垂直分（纵向），按照不同的业务类型划分应用，比如进销存系统可以划分为三个独立的应用，这是面向业务广度的划分。

     应用的合反映应用之间如何协作，共同完成复杂的业务case，主要体现在应用之间的通讯机制和数据格式，通讯机制可以是同步调用/异步消息/共享DB访问等，数据格式可以是文本/XML/JSON/二进制等。

     应用的分偏向于业务，反映业务架构，应用的合偏向于技术，影响技术架构。分降低了业务复杂度，系统更有序，合增加了技术复杂度，系统更无序。

     应用架构的本质是通过系统拆分，平衡业务和技术复杂性，保证系统形散神不散。

     系统采用什么样的应用架构，受业务复杂性影响，包括企业发展阶段和业务特点；同时受技术复杂性影响，包括IT技术发展阶段和内部技术人员水平。业务复杂性（包括业务量大）必然带来技术复杂性，应用架构目标是解决业务复杂性的同时，避免技术太复杂，确保业务架构落地。

3、数据架构

数据架构指导数据库的设计.  不仅仅要考虑开发中涉及到的数据库，实体模型，也要考虑物理架构中数据存储的设计。


			
No.
			
			

			
考虑的方面
			
			

			
产出物
			
			

			
工具
			
			

			
说明
			
		

			
1
			
			

			
数据是集中还是分布存储的？如何考虑分布式存储？
			
			

			
数据架构图
			
			

			
 
			
			

			
 
			
		

			
2
			
			

			
领域模型到数据库表的转换？表结构关系的设计？
			
			

			
逻辑模型

			
物理模型

			
ER图
			
			

			
Power Designer

			
Visio
			
			

			
 
			
		

			
3
			
			

			
实体如何设计？充血模型和贫血模型？
			
			

			
UML类图
			
			

			
 
			
			

			
 
			
		

			
4
			
			

			
使用什么数据库？关系型还是非关系型？
			
			

			
选型结果
			
		
 

4、代码架构（也叫开发架构）：

子系统代码架构主要为开发人员提供切实可行的指导，如果代码架构设计不足，就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件，结果公司整体架构设计就会失控。

代码架构主要定义内容：

一、代码单元:

        1、配置设计

        2、框架、类库。

二、代码单元组织：

       1、编码规范，编码的惯例。

       2、项目模块划分

       3、顶层文件结构设计，比如mvc设计。

       4、依赖关系


			
No.
			
			

			
考虑的方面
			
			

			
产出物
			
			

			
工具
			
			

			
说明
			
		

			
1
			
			

			
分层结构设计
			
			

			
分层架构图（开发架构图）
			
			

			
各种绘图工具
			
			

			
好的分层结构支持自动化测试
			
		

			
2
			
			

			
开发技术选项
			
			

			
开发语言

			
开发框架

			
开发工具
			
			

			
 
			
			

			
考虑商用产品、开源框架、自研框架
			
		

			
3
			
			

			
模块划分
			
			

			
源码工程；Project目录结构；

			
分包(分库)
			
			

			
 
			
			

			
 
			
		

			
4
			
			

			
开发规范
			
			

			
开发/编码规范文档；
			
			

			
 
			
			

			
 
			
		

			
5
			
			

			
软件质量属性
			
			

			
分析和决策结果
			
			

			
 
			
			

			
考虑运行期和开发期软件质量属性，并权衡利弊进行决策。
			
		
最好的样本是参考现有《阿里巴巴Java开发手册》。

 

5、技术架构

     技术架构：确定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm等），这些运行组件之间的关系，以及部署到硬件的策略。

     技术架构主要考虑系统的非功能性特征，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。

　系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这也是架构设计工作中最为困难的工作。

 

6、部署拓扑架构图（实际物理架构图）：

      拓扑架构，包括架构部署了几个节点，节点之间的关系，服务器的高可用，网路接口和协议等，决定了应用如何运行，运行的性能，可维护性，可扩展性，是所有架构的基础。这个图主要是运维工程师主要关注的对象。



物理架构主要考虑硬件选择和拓扑结构，软件到硬件的映射，软硬件的相互影响。


			
 
			
			

			
考虑的方面
			
			

			
产出物
			
			

			
工具
			
			

			
说明
			
		

			
1
			
			

			
网络方面：网络拓扑；网络设备；安全机制
			
			

			
拓扑图

			
安全规范
			
			

			
 
			
			

			
 
			
		

			
2
			
			

			
性能方面：可靠性、可伸缩性
			
			

			
需要什么样设备性能
			
			

			
 
			
			

			
 
			
		

			
3
			
			

			
部署方面：集中式还是分布式；组件部署
			
			

			
部署图

			
 
			
			

			
 
			
			

			
 
			
		
 

三、架构级别

我们使用金字塔的架构级别来说明,上层级别包含下层：系统级、应用级、模块级、代码级。




	
系统级，即整个系统内各部分的关系以及如何治理：分层。
	
	

	
应用级，即单个应用的整体架构，及其与系统内单个应用的关系等。
	
	

	
模块级，即应用内部的模块架构，如代码的模块化、数据和状态的管理等。
	
	

	
代码级，即从代码级别保障架构实施。
	
战略设计与战术设计

基于架构金字塔，我们有了系统架构的战略设计与战术设计的完美结合：


	
战略设计：业务架构用于指导架构师如何进行系统架构设计。
	
	

	
战术设计：应用架构要根据业务架构来设计。
	
	

	
战术实施：应用架构确定以后，就是技术选型。
	


 

四、应用架构演进

业务架构是生产力，应用架构是生产关系，技术架构是生产工具。业务架构决定应用架构，应用架构需要适配业务架构，并随着业务架构不断进化，同时应用架构依托技术架构最终落地。    

 

架构演进路程：单体应用->分布式应用服务化-> 微服务

 

1、单体应用

企业一开始业务比较简单，只应用某个简单场景，应用服务支持数据增删改查和简单的逻辑即可，单体应用可以满足要求。

典型的三级架构，前端（Web/手机端）+中间业务逻辑层+数据库层。这是一种典型的Java Spring MVC或者Python Django框架的应用。其架构图如下所示： 



针对单体应用，非功能性需求的做法：

   1、性能需求：使用缓存改善性能

   2、并发需求：使用集群改善并发

   3、读写分离：数据库地读写分离

  4、使用反向代理和cdn加速

  5、使用分布式文件和分布式数据库

单体架构的应用比较容易部署、测试， 在项目的初期，单体应用可以很好地运行。然而，随着需求的不断增加， 越来越多的人加入开发团队，代码库也在飞速地膨胀。慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。下面是单体架构应用的一些缺点：

复杂性高：

以一个百万行级别的单体应用为例，整个项目包含的模块非常多、模块的边界模糊、 依赖关系不清晰、 代码质量参差不齐、 混乱地堆砌在一起。可想而知整个项目非常复杂。 每次修改代码都心惊胆战， 甚至添加一个简单的功能， 或者修改一个Bug都会带来隐含的缺陷。

技术债务： 随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务， 并且越积 越多。“ 不坏不修”， 这在软件开发中非常常见， 在单体应用中这种思想更甚。 已使用的系统设计或代码难以被修改，因为应用程序中的其他模块可能会以意料之外的方式使用它。

部署频率低： 随着代码的增多，构建和部署的时间也会增加。而在单体应用中， 每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时长、 影响范围大、 风险高， 这使得单体应用项目上线部署的频率较低。 而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错率比较高。

可靠性差： 某个应用Bug，例如死循环、内存溢出等， 可能会导致整个应用的崩溃。

扩展能力受限： 单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。例如，应用中有的模块是计算密集型的，它需要强劲的CPU； 有的模块则是IO密集型的，需要更大的内存。 由于这些模块部署在一起，不得不在硬件的选择上做出妥协。

阻碍技术创新： 单体应用往往使用统一的技术平台或方案解决所有的问题， 团队中的每个成员 都必须使用相同的开发语言和框架，要想引入新框架或新技术平台会非常困难。

2、分布式

随着业务深入，业务要求的产品功能越来越多，每个业务模块逻辑也都变得更加复杂，业务的深度和广度都增加，使得单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，增加新功能开发周期越来越长，维护成本越来越高。

这时需要对系统按照业务功能模块拆分，将各个模块服务化，变成一个分布式系统。业务模块分别部署在不同的服务器上，各个业务模块之间通过接口进行数据交互。



该架构相对于单体架构来说，这种架构提供了负载均衡的能力，大大提高了系统负载能力，解决了网站高并发的需求。另外还有以下特点：

降低了耦合度：把模块拆分，使用接口通信,降低模块之间的耦合度。

责任清晰：把项目拆分成若干个子项目，不同的团队负责不同的子项目。

扩展方便：增加功能时只需要再增加一个子项目，调用其他系统的接口就可以。

部署方便：可以灵活的进行分布式部署。

提高代码的复用性：比如Service层，如果不采用分布式rest服务方式架构就会在手机Wap商城，微信商城，PC，Android，iOS每个端都要写一个Service层逻辑，开发量大，难以维护一起升级，这时候就可以采用分布式rest服务方式，公用一个service层。

缺点：系统之间的交互要使用远程通信，接口开发增大工作量，但是利大于弊。

 

3、微服务

      紧接着业务模式越来越复杂，订单、商品、库存、价格等各个模块都很深入，比如价格区分会员等级，访问渠道（app还是PC），销售方式（团购还是普通）等，还有大量的价格促销，这些规则很复杂，容易相互冲突，需要把分散到各个业务的价格逻辑进行统一管理，以基础价格服务的方式透明地提供给上层应用，变成一个微内核的服务化架构，即微服务。

      微服务的特点：

易于开发和维护： 一个微服务只会关注一个特定的业务功能，所以它业务清晰、代码量较少。 开发和维护单个微服务相对简单。而整个应用是由若干个微服务构建而成的，所以整个应用也会被维持在一个可控状态。

单个微服务启动较快： 单个微服务代码量较少， 所以启动会比较快。

局部修改容易部署： 单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。 一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。

技术栈不受限：在微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈。例如某些服务可使用关系型数据库MySQL；某些微服务有图形计算的需求，可以使用Neo4j；甚至可根据需要，部分微服务使用Java开发，部分微服务使用Node.js开发。

微服务虽然有很多吸引人的地方，但它并不是免费的午餐，使用它是有代价的。使用微服务架构面临的挑战。

运维要求较高：更多的服务意味着更多的运维投入。在单体架构中，只需要保证一个应用的正常运行。而在微服务中，需要保证几十甚至几百个服务服务的正常运行与协作，这给运维带来了很大的挑战。

分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。

接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有使用了该接口的微服务都需要做调整。

重复劳动：很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而导致代码重复。尽管可以使用共享库来解决这个问题（例如可以将这个功能封装成公共组件，需要该功能的微服务引用该组件），但共享库在多语言环境下就不一定行得通了。

     
   

五、衡量架构的合理性

架构为业务服务，没有最优的架构，只有最合适的架构， 架构始终以高效，稳定，安全为目标来衡量其合理性。

合理的架构设计：

1、业务需求角度

1、能解决当下业务需求和问题

2、高效完成业务需求: 能以优雅且可复用的方式解决当下所有业务问题

3、前瞻性设计: 能在未来一段时间都能以第2种方式满足业务，从而不会每次当业务进行演变时，导致架构翻天覆地的变化。

 

2、非业务需求角度

（一）、稳定性。指标：

1. 高可用：要尽可能的提高软件的可用性，我想每个操作人都不愿意看到自己的工作无法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来一步一步推进。

（二）、高效指标：

1. 文档化：不管是整体还是部分的整个生命周期内都必须做好文档化，变动的来源包括但不限于BUG，需求。

2. 可扩展：软件的设计秉承着低耦合的理念去做，注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代，并且支持在适时对架构做出重构。

3. 高复用：为了避免重复劳动，为了降低成本，我们希望能够重用之前的代码、之前的设计。这点对于架构环境的依赖是最大的。

（三）、安全指标

1. 安全：组织的运作过程中产生的数据都是具有商业价值的，保证数据的安全也是刻不容缓的一部分。以免出现XX门之类丑闻。加密、https等为普遍手段

六、常见架构误区

●开高走落不到实处

● 遗漏关键性约束与非功能需求

● 为虚无的未来埋单而过度设计

● 过早做出关键性决策

● 客户说啥就是啥成为传话筒

● 埋头干活儿缺乏前瞻性

● 架构设计还要考虑系统可测性

● 架构设计不要企图一步到位

误区1——架构专门由架构师来做，业务开发人员无需关注

架构的再好，最终还是需要代码来落地，并且组织越大这个落地的难度越大。不单单是系统架构，每个解决方案每个项目也由自己的架构，如分层、设计模式等。如果每一块砖瓦不够坚固，那么整个系统还是会由崩塌的风险。所谓“千里之堤，溃于蚁穴”。

误区2——架构师确定了架构蓝图之后任务就结束了

架构不是“空中楼阁”，最终还是要落地的，但是架构师完全不去深入到第一线怎么知道“地”在哪？怎么才能落的稳稳当当。

误区3——不做出完美的架构设计不开工

世上没有最好架构，只有最合适的架构,不要企图一步到位。我们需要的不是一下子造出一辆汽车，而是从单轮车 --> 自行车 --> 摩托车，最后再到汽车。想象一下2年后才能造出的产品，当初市场还存在吗？

误区4—— 为虚无的未来埋单而过度设计

在创业公司初期，业务场景和需求边界很难把握，产品需要快速迭代和变现，需求频繁更新，这个时候需要的是快速实现。不要过多考虑未来的扩展，说不定功能做完，效果不好就无用了。如果业务模式和应用场景边界都已经比较清晰，是应该适当的考虑未来的扩展性设计。

 

误区5——一味追随大公司的解决方案

由于大公司巨大成功的光环效应，再加上从大公司挖来的技术高手的影响，网站在讨论架构决策时，最有说服力的一句话就成了“淘宝就是这么搞的”或者“腾讯 就是这么搞的”。

大公司的经验和成功模式固然重要，值得学习借鉴，但如果因此而变得盲从，就失去了坚持自我的勇气，在架构演化的道路上迟早会迷路。

 

误区6——为了技术而技术，

技术是为业务而存在的，除此毫无意义。在技术选型和架构设计中，脱离网站业务发展的实际，一味追求时髦的新技术，可能会将技术发展引入崎岖小道，架构之路越走越难。考虑实现成本、时间、人员等各方面都要综合考虑，理想与现实需要折中。

 

 

七、架构书籍推荐

 1. 《大型网站技术架构：核心原理与案例分析》

这是比较早，比较系统介绍大型网站技术架构的书，通俗易懂又充满智慧，即便你之前完全没接触过网站开发，通读前几章，也能快速获取到常见的网站技术架构及其应用场景。非常赞。

 2. 《亿级流量网站架构核心技术》

相比《大型网站技术架构》的高屋建瓴，开涛的这本《亿级流量网站架构核心技术》则落实到细节，网站架构中常见的各种技术，比如缓存、队列、线程池、代理……，统统都讲到了，而且配有核心代码。甚至连 Nginx 的配置都有！

如果你想在实现大流量网站时找参考技术和代码，这本书最合适啦。

3. 《架构即未来》

这是一本“神书”啦，超越具体技术层面，着重剖析架构问题的根源，帮助我们弄清楚应该以何种方式管理、领导、组织和配置团队。

4. 《分布式服务架构：原理、设计与实战》

这本书全面介绍了分布式服务架构的原理与设计，并结合作者在实施微服务架构过程中的实践经验，总结了保障线上服务健康、可靠的最佳方案，是一本架构级、实战型的重量级著作。

5. 《聊聊架构》

这算是架构方面的一本神书了，从架构的原初谈起，从业务的拆分谈起，谈到架构的目的，架构师的角色，架构师如何将架构落地……强烈推荐。

不过，对于没有架构实践经验的小伙伴来讲，可能会觉得这本书比较虚，概念多，实战少。但如果你有过一两个项目的架构经验，就会深深认同书中追本溯源探讨的架构理念。

6. 《软件架构师的12项修炼》

大多数时候所谓的“技术之玻璃天花板”其实只是缺乏软技能而已。这些技能可以学到，缺乏的知识可以通过决定改变的努力来弥补。

 

总结参考：

《大型网站技术架构》、《软件架构师设计》《TOGAF9》