精华内容
下载资源
问答
  • 分层架构

    2020-04-13 09:37:46
    分层架构是很常见的架构模式,也叫N层架构,通常情况下按至少是2层,一般不超过5层。 CS架构和BS架构划分的对象是整个业务系统,划分的维度是用户交互。 mvc架构mvp架构划分的对象是单个业务子系统,划分的...

    分层架构是很常见的架构模式,也叫N层架构,通常情况下按至少是2层,一般不超过5层。

     

    CS架构和BS架构划分的对象是整个业务系统,划分的维度是用户交互。

     

    mvc架构mvp架构划分的对象是单个业务子系统,划分的维度是职责,将不同的职责划分到独立层。

     

    逻辑分层架构划分的对象可以是单个业务子系统,也可以是整个业务系统,划分的维度也是职责。

     

    无论采取何种分层架构,分层架构设计最核心的一点就是需要保证各层之间的差异足够清晰,边界足够明显。

     

    分层架构之所以能够较好的支撑系统扩展,在于隔离关注点。

     

    分层架构的一个特点就是层层传递,分层架构的一个典型缺点就是性能。

    展开全文
  • AUTOSAR分层架构

    2018-01-09 22:03:53
    AUTOSAR分层架构 AUTOSAR分层架构 AUTOSAR分层架构AUTOSAR分层架构
  • 浅析.NET逻辑分层架构

    2020-10-23 09:26:24
    主要介绍了.NET逻辑分层架构分层架构的三个基本层次分别为:表示层、业务逻辑层和数据访问层,感兴趣的小伙伴们可以参考一下
  • Java分层架构

    2021-01-20 03:34:32
     java分层架构  三层架构(3-tier application) 通常意义上的三层架构是将整个业务应用划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。区分层次的目的即为了“高内聚,低耦合”的思想。  概念简介  ...
  • • 互联网分层架构的本质,是数据的移动 • 互联网分层架构中,数据的传输格式(协议)与数据在各层次的形态很重要 • 互联网分层架构演进的核心原则与方法:封装与复用
  • .NET分层架构设计模式

    2011-06-10 16:10:07
    .NET分层架构.NET分层架构.NET分层架构.NET分层架构.NET分层架构.NET分层架构.NET分层架构.NET分层架构.NET分层架构.NET分层架构.NET分层架构.NET分层架构.NET分层架构.NET分层架构.NET分层架构.NET分层架构
  • 互联网分层架构演进 目录 互联网分层架构本质 互联网分层架构演进 总结 一互联网分层架构本质 典型分层架构 传统三层架构 服务化后四层架构 MVC服务端与客户端 互联网分层架构的本质 数据处理 -> 各层次的形态 数据...
  • 网络分层架构(七/四层协议)

    万次阅读 多人点赞 2019-03-11 17:02:12
    网络分层架构 业内普遍的分层方式有两种。OSI七层模型 和TCP/IP四层模型。 OSI七层模型:物、数、网、传、会、表、应 TCP/IP四层模型:链、网、传、应 1) 物理层:主要定义物理设备标准,如网线的接口类型、光纤的...

    网络分层架构

    在这里插入图片描述
    业内普遍的分层方式有两种。OSI七层模型 和TCP/IP四层模型。
    OSI七层模型:物、数、网、传、会、表、应
    TCP/IP四层模型:链、网、传、应
    1) 物理层:主要定义物理设备标准,如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。它的主要作用是传输比特流(就是由1、0转化为电流强弱来进行传输,到达目的地后再转化为1、0,也就是我们常说的数模转换与模数转换)。这一层的数据叫做比特。
    2)数据链路层:定义了如何让格式化数据以帧为单位进行传输,以及如何让控制对物理介质的访问。这一层通常还提供错误检测和纠正,以确保数据的可靠传输。如:串口通信中使用到的115200、8、N、1
    3)网络层:在位于不同地理位置的网络中的两个主机系统之间提供连接和路径选择。Internet的发展使得从世界各站点访问信息的用户数大大增加,而网络层正是管理这种连接的层。
    4) 传输层:定义了一些传输数据的协议和端口号(WWW端口80等),如:TCP(传输控制协议,传输效率低,可靠性强,用于传输可靠性要求高,数据量大的数据),UDP(用户数据报协议,与TCP特性恰恰相反,用于传输可靠性要求不高,数据量小的数据,如QQ聊天数据就是通过这种方式传输的)。 主要是将从下层接收的数据进行分段和传输,到达目的地址后再进行重组。常常把这一层数据叫做段。
    5) 会话层:通过传输层(端口号:传输端口接收端口)建立数据传输的通路。主要在你的系统之间发起会话或者接受会话请求(设备之间需要互相认识可以是IP也可以是MAC或者是主机名)。
    6)表示层:可确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。例如,PC程序与另一台计算机进行通信,其中一台计算机使用扩展二一十进制交换码(EBCDIC),而另一台则使用美国信息交换标准码(ASCII)来表示相同的字符。如有必要,表示层会通过使用一种通格式来实现多种数据格式之间的转换。
    7) 应用层:是最靠近用户的OSI层。这一层为用户的应用程序(例如电子邮件、文件传输和终端仿真)提供网络服务。

    分层功能示意:
    OSI七层模型结构体: 物、数、网、传、会、表、应
    TCP/IP 四层模型:数、网、传、应
    在这里插入图片描述

    链路层:
    

    以太网规定,连入网络的所有设备,都必须具有“网卡”接口。数据包必须是从一块网卡,传送到另一块网卡。通过网卡能够使不同的计算机之间连接,从而完成数据通信等功能。网卡的地址——MAC 地址(全球唯一),就是数据包的物理发送地址和物理接收地址。

    链路层速记:ARP(核心协议)
    mac —— 目标mac
    ARP 协议作用: 借助 IP 获取 mac 地址。

    *: MAC 地址是绑定在网卡上的
    IP:地址则是管理员分配的

    网络层:
    

    网络层的作用是引进一套新的地址,使得我们能够区分不同的计算机是否属于同一个子网络。这套地址就叫做“网络地址”,这是我们平时所说的IP地址。网络层协议包含的主要信息是源IP和目的IP。

    网络层速记:IP(核心协议)
    源IP —— 目标IP
    IP协议的作用: 在 网络环境中唯一标识一台主机。
    IP地址本质:2进制数。—— 点分十进制 IP地址 (string)
    IP和MAC的作用:
    网络地址(IP):帮助我们确定计算机所在的子网络
    MAC 地址:则将数据包送到该子网络中的目标网卡。
    处理顺序:从逻辑上可以推断,必定是先处理网络地址,然后再处理 MAC 地址

    传输层:
    

    端口:确定进程
    1, 对于同一个端口,在不同系统中对应着不同的进程
    2,对于同一个系统,一个端口只能被一个进程拥有

    传输层速记:TCP / UDP(核心协议)
    port —— 在 一台主机上唯一标识一个进程。

    应用关系:
    

    通过网络层IP确认交互端,通过MAC确认信息发送目标,最终通过端口指定要发生信息交互的程序

    在这里插入图片描述

    应用层
    

    接到传输层传递过来的数据就要对数据进行解析,应用层就是规定程序的数据格式
    应用层速记:ftp、http、自定义
    对数据进行封装。 解封装

    TCP/IP:TCP/IP协议是一个大家族,不仅仅只有TCP和IP协议,它还包括其它的协议

    网络通信过程

    数据通信:
    封装: 应用层 —— 传输层 —— 网络层 —— 链路层 。 没有经过封装的数据,不能在网
    络环境中传递。
    解封装 : 链路层 —— 网络层 —— 传输层 —— 应用层

    在这里插入图片描述
    socket:
    套接字。
    网络通信过程中,socket 一定是成对出现的。
    1,在TCP/IP协议中,“IP地址+TCP或UDP端口号”唯一标识网络通讯中的一个进程。
    2,IP地址+端口号:就对应一个socket。
    3,欲建立连接的两个进程各自有一个socket来标识,那么这两个socket组成的socket pair就唯一标识
    一个连接。
    4,Socket来描述网络连接的一对一关系。
    5,常用的Socket类型有两种:流式Socket(SOCK_STREAM)和数据报式Socket(SOCK_DGRAM)。
    a)流式是一种面向连接的Socket,针对于面向连接的TCP服务应用;
    b)据报式Socket是一种无连接的Socket,对应于无连接的UDP服务应用。
    关于通信:

    1. mac地址(不需要用户指定) (ARP 协议)Ip ——> mac
    2. IP 地址 (需要用户指定) —— 确定主机
    3. port 端口号 (需要用户指定) —— 确定程序
    4. 不能使用系统占用的默认端口。 5000+ 端口我们使用 (8080)
    5. 65535为端口上限。

    C/S架构设计的优缺点:
    优点:1,性能:客户端位于目标主机上可以保证性能,将数据缓存至客户端本地,从而提高数据传
    输效率。
    2,协议灵活:户端和服务器程序由一个开发团队创作
    缺点:1,成本高 客户端服务端都需要独立开发
    2,独立安装客户端对用户来说有安全隐患

    TCP:CS开发架构(代码层面)

    在这里插入图片描述
    在这里插入图片描述

    TCP通信过程:

    三次握手:
    	1. 主动发起请求端, 发送 SYN 
    	2. 被动建立连接请求端 , 应答ACK 同时 发送 SYN
    	3. 主动发起请求端,发送应答 ACK
    	* 标志 TCP 三次握手建立完成。 —— server:Accept() 返回 。— client:Dial() 返回。
    
    四次挥手:
    	1. 主动关闭连接请求端, 发送 FIN
    	2. 被动关闭连接请求端 ,应答 ACK
    					标志。半关闭完成。 —— close()
    	3. 被动关闭连接请求端 ,发送 FIN
    	4.  主动关闭连接请求端,应答 ACK
    					标志。四次挥手建立完成。 —— close().
    

    在这里插入图片描述
    TCP深入机制
    在这里插入图片描述

    //三次握手和四次挥手
    在这里插入图片描述

    TCP转换图解析:

    1,主动发起连接请求端口close>完成三次握手>EATABLISEHED(数据通信状态)> Dial()函数返回

    2,被动发起连接请求端: CLOSED > 调用Accept()函数>LISTEN 完成三次握手 >ESTABLISEHED (数据通信状态)>Accept()函数返回>数据传递期间 —— ESTABLISEHED (数据通信状态)

    主动关闭连接请求端:ESTABLISEHED>FIN_WAIT_2 (半关闭)>TIME_WAIT >2MSL >确认最后一
    个ACK被对端成功接收>CLOSE>半关闭、TIME_WAIT、2MSL
    >只会出现在 “主动关闭连接请求端”

    被动关闭连接请求端:ESTABLISEHED>CLOSE

    查看状态命令:
    windows:netstat -an | findstr 8001(端口号)
    Linux: netstat -apn | grep 8001

    展开全文
  • .NET逻辑分层架构总结

    2020-10-24 02:14:03
    本人将从另一个角度来解析.NET分层架构的真正奥秘。分层,一些技术功底比较薄弱的程序员听到分层就会联想到三层架构(BLL,DAL之类的),其实不是,分层是一个很大的技术框架思想,三层架构只不过是对普通的信息系统来...
  • 在应用系统开发中,采用严格的、单一的、真正的的分层架构是可以的,但实际上我们已经采用了多种架构模式设计系统。当多种不同范式的架构混合在一起,你会不会出现“指鹿为马”的现象呢? 在研究分层架构时,常通过...
  • net 分层架构实战

    2012-06-11 13:36:58
    分层架构实战
  • 以太网分层架构.ppt

    2020-08-15 03:46:17
    Chapter 14 Ethernet 以太网分层架构 传统以太网 高速以太网 千兆以太网 College of Information Engineering 以太网分层架构 Fig14.1(P.229) 按照IEEE802系列标准的约定,数据链路 层分为两个子层 LLC Sublayer逻辑...
  • 一个非常好的文档来介绍DDD分层架构参考代码目录结构,接口层,应用层,领域层和基础层等!
  • javaweb分层架构

    2013-12-30 10:33:33
    javaweb项目开发三大框架的描述!以及javaweb的分层架构的方式!
  • ECU软件的AUTOSAR分层架构详解,详细精确的介绍ECU软件中AUTOSAR的分层架构的细节,对理解及应用AUTOSAR非常有用
  • net分层架构实战中.pdf

    2020-04-19 20:34:56
    .NET 分层架构实战中 /leoo2sk/default.html?page=4 一综述 通过浏览博客园的文章发现很多朋友对分层架构特别感兴趣通过做一个完整的案例来讨 论分层架构的基本方法这样会直观很多希望在这个文章系列的写作过程中能...
  • 分层架构的单元测试

    2015-09-05 20:32:55
    分层架构下的单元测试,使用Mock的机制剥离依赖关系
  • 一文读懂分层架构

    万次阅读 多人点赞 2018-07-23 18:40:33
    分层架构由来已久,将一个软件系统进行分层,似乎已经成为了每个开发人员的固有意识,甚至不必思考即可自然得出。这其中最为经典的就是三层架构以及领域驱动设计提出的四层架构。

    作者简介

    张逸,曾先后就职于中兴通讯、惠普 GDCC、中软国际、ThoughtWorks 等大型中外企业,任职角色为高级软件工程师、架构师、技术总监、首席咨询师。GitChat 畅销精品课作者。

    精通包括 Java、Scala、Python、C#、JavaScript、Ruby 等多种语言,熟练掌握面向对象思想、测试驱动开发与重构、领域驱动设计、函数式编程、架构、大数据分析、敏捷与过程改进,并致力于大型软件企业的面向服务系统架构设计、大数据平台架构设计以及互联网 Web 系统架构设计。

    著译作包括《软件设计精要与模式》、《Java 设计模式》、《恰如其分的软件架构》、《WCF 服务编程》、《人件》、《重构——改善既有代码设计》评注版、以及《架构之美(Beatiful Architecture)》评注版。

    版权声明
    本文及文中所涉及课程均为 GitChat 平台独家发布,未经授权不得转载。

    认识分层架构

    分层架构是运用最为广泛的架构模式,几乎每个软件系统都需要通过层(Layer)来隔离不同的关注点(Concern Point),以此应对不同需求的变化,使得这种变化可以独立进行;此外,分层架构模式还是隔离业务复杂度与技术复杂度的利器,《领域驱动设计模式、原理与实践》写道:

    为了避免将代码库变成大泥球(BBoM)并因此减弱领域模型的完整性且最终减弱可用性,系统架构要支持技术复杂性与领域复杂性的分离。引起技术实现发生变化的原因与引起领域逻辑发生变化的原因显然不同,这就导致基础设施和领域逻辑问题会以不同速率发生变化。

    这里所谓的“以不同速率发生变化”,其实就是引起变化的原因各有不同,这正好是单一职责原则(Single-Responsibility Principle,SRP)的体现。Robert Martin 认为单一职责原则就是“一个类应该只有一个引起它变化的原因”,换言之,如果有两个引起类变化的原因,就需要分离。单一职责原则可以理解为架构原则,这时要考虑的就不是类,而是层次。我们为什么要将业务与基础设施分开?正是因为引起它们变化的原因不同。

    经典分层架构

    分层架构由来已久,将一个软件系统进行分层,似乎已经成为了每个开发人员的固有意识,甚至不必思考即可自然得出。这其中最为经典的就是三层架构以及领域驱动设计提出的四层架构。

    经典三层架构

    在软件架构中,经典三层架构自顶向下由用户界面层(User Interface Layer)、业务逻辑层(Business Logic Layer)与数据访问层(Data Access Layer)组成。该分层架构之所以能够流行,是有其历史原因的。在提出该分层架构的时代,多数企业系统往往较为简单,本质上都是一个单体架构(Monolithic Architecture)的数据库管理系统。这种分层架构已经是Client-Server架构的进化了,它有效地隔离了业务逻辑与数据访问逻辑,使得这两个不同关注点能够相对自由和独立地演化。一个经典的三层架构如下所示:

    领域驱动设计的经典分层架构

    领域驱动设计在经典三层架构的基础上做了进一步改良,在用户界面层与业务逻辑层之间引入了新的一层,即应用层(Application Layer)。同时,一些层次的命名也发生了变化。将业务逻辑层更名为领域层自然是题中应有之义,而将数据访问层更名为基础设施层(Infrastructure Layer),则突破了之前数据库管理系统的限制,扩大了这个负责封装技术复杂度的基础层次的内涵。下图为 Eric Evans 在其经典著作《领域驱动设计》中的分层架构:

    追溯分层架构的本源

    当分层架构变得越来越普及时,我们的设计反而变得越来越僵化。一部分软件设计师并未理解分层架构的本质,只知道依样画葫芦地将分层应用到系统中。要么采用经典的三层架构,要么遵循领域驱动设计改进的四层架构,却未思考和叩问如此分层究竟有何道理?这是分层架构被滥用的根源。

    视分层(Layer)为一个固有的架构模式,其滥觞应为 Frank Buschmann 等人著的《面向模式的软件架构》第一卷《模式系统》。该模式参考了 ISO 对 TCP/IP 协议的分层。《模式系统》对分层的描述为:

    分层架构模式有助于构建这样的应用:它能被分解成子任务组,其中每个子任务组处于一个特定的抽象层次上。

    显然,这里所谓的“分层”首先是一个逻辑的分层,对子任务组的分解需要考虑抽象层次,一种水平的抽象层次。既然为水平的分层,必然存在层的高与低;而抽象层次的不同,又决定了分层的数量。因此,对于分层架构,我们需要解决如下问题:

    • 分层的依据与原则是什么?
    • 层与层之间是怎样协作的?

    分层的依据与原则

    我们之所以要以水平方式对整个系统进行分层,是我们下意识地确定了一个认知规则:机器为本,用户至上。机器是运行系统的基础,而我们打造的系统却是为用户提供服务的。分层架构中的层次越往上,其抽象层次就越面向业务,面向用户;分层架构中的层次越往下,其抽象层次就变得越通用,面向设备。为什么经典分层架构为三层架构?正是源于这样的认知规则:其上,面向用户的体验与交互;其中,面向应用与业务逻辑;其下,面对各种外部资源与设备。在进行分层架构设计时,我们完全可以基于这个经典的三层架构,沿着水平方向进一步切分属于不同抽象层次的关注点。因此,分层的第一个依据是基于关注点为不同的调用目的划分层次。以领域驱动设计的四层架构为例,之所以引入应用层(Application Layer),就是为了给调用者提供完整的业务用例。

    分层的第二个依据是面对变化。分层时应针对不同的变化原因确定层次的边界,严禁层次之间互相干扰,或者至少将变化对各层带来的影响降到最低。例如数据库结构的修改自然会影响到基础设施层的数据模型以及领域层的领域模型,但当我们仅需要修改基础设施层中数据库访问的实现逻辑时,就不应该影响到领域层了。层与层之间的关系应该是正交的。所谓“正交”,并非二者之间没有关系,而是垂直相交的两条直线。唯一相关的依赖点是这两条直线的相交点,即两层之间的协作点。正交的两条直线,无论哪条直线进行延伸,都不会对另一条直线产生任何影响(指直线的投影)。如果非正交,即“斜交”,当一条直线延伸时,它总是会投影到另一条直线,这就意味着另一条直线会受到它变化的影响。

    在进行分层时,我们还应该保证同一层的组件处于同一个抽象层次。这是分层架构的设计原则,它借鉴了 Kent Beck 在 Smalltalk Best Practice Patterns 一书提出的“组合方法”模式。该模式要求一个方法中的所有操作处于相同的抽象层,这就是所谓的“单一抽象层次原则(SLAP)”。这一原则可以运用到分层架构中。例如在一个基于元数据的多租户报表系统中,我们特别定义了一个引擎层(engine layer),这是一个隐喻,相当于为报表系统提供报表、实体与数据的驱动引擎。引擎层之下,是基础设施层,提供了多租户、数据库访问与元数据解析与管理等功能。在引擎层之上是一个控制层,通过该控制层的组件可以将引擎层的各个组件组合起来。分层架构的顶端是面向用户的用户展现层。如下图所示:

    层之间的协作

    在我们固有的认识中,分层架构的依赖都是自顶向下传递的,这也符合大多数人对分层的认知模型。从抽象层次看,层次越处于下端,就会变得越通用越公共,与具体的业务隔离得越远。出于重用的考虑,这些通用和公共的功能往往会被单独剥离出来形成平台或框架,在系统边界内的低层,除了面向高层提供足够的实现外,就都成了平台或框架的调用者。换言之,越是通用的层,越有可能与外部平台或框架形成强依赖。若依赖的传递方向仍然采用自顶向下,就会导致系统的业务对象也随之依赖于外部平台或框架。

    依赖倒置原则(Dependency Inversion Principle,DIP)提出了对这种自顶向下依赖的挑战,它要求“高层模块不应该依赖于低层模块,二者都应该依赖于抽象。”这个原则正本清源,给了我们当头棒喝——谁规定在分层架构中,依赖就一定要沿着自顶向下的方向传递?我们常常理解依赖,是因为被依赖方需要为依赖方(调用方)提供功能支撑,这是从功能重用的角度来考虑的。但我们不能忽略变化对系统产生的影响!与建造房屋一样,我们自然希望分层的模块“构建”在稳定的模块之上。谁更稳定?抽象更稳定。因此,依赖倒置原则隐含的本质是:我们要依赖不变或稳定的元素(类、模块或层)。也就是该原则的第二句话:抽象不应该依赖于细节,细节应该依赖于抽象。

    这一原则实际是“面向接口设计”原则的体现,即“针对接口编程,而不是针对实现编程”。高层模块对低层模块的实现是一无所知的,带来的好处是:

    • 低层模块的细节实现可以独立变化,避免变化对高层模块产生污染
    • 在编译时,高层模块可以独立于低层模块单独存在
    • 对于高层模块而言,低层模块的实现是可替换的

    倘若高层依赖于低层的抽象,必然会面对一个问题:如何将具体的实现传递给高层的类?由于在高层通过接口隔离了对具体实现的依赖,就意味着这个具体依赖被转移到了外部,究竟使用哪一种具体实现,由外部的调用者来决定。只有在运行调用者代码时,才将外面的依赖传递给高层的类。Martin Fowler 形象地将这种机制称为“依赖注入(dependency injection)”。

    为了更好地解除高层对低层的依赖,我们往往需要将依赖倒置原则与依赖注入结合起来。

    层之间的协作并不一定是自顶向下的传递通信,也有可能是自底向上通信,例如在 CIMS(计算机集成制造系统)中,往往会由低层的设备监测系统监测(侦听)设备状态的变化。当状态发生变化时,需要将变化的状态通知到上层的业务系统。如果说自顶向下的消息传递往往被描述为“请求(或调用)”,则自底向上的消息传递则往往被形象地称之为“通知”。倘若我们颠倒一下方向,自然也可以视为这是上层对下层的观察,故而可以运用观察者模式(Observer Pattern),在上层定义 Observer 接口,并提供 update() 方法供下层在感知状态发生变更时调用。或者,我们也可以认为这是一种回调机制。虽然本质上这并非回调,但设计原理是一样的。

    如果采用了观察者模式,则与前面讲述的依赖倒置原则有差相仿佛之意,因为下层为了通知上层,需要调用上层提供的 Observer 接口。如此看来,无论是上层对下层的“请求(或调用)”,抑或下层对上层的“通知”,都颠覆了我们固有思维中那种高层依赖低层的理解。

    现在,我们对分层架构有了更清醒的认识。我们必须要打破那种谈分层架构必为经典三层架构又或领域驱动设计推荐的四层架构这种固有思维,而是将分层视为关注点分离的水平抽象层次的体现。既然如此,架构的抽象层数就不是固定的,甚至每一层的名称也未必遵循固有(经典)的分层架构要求。设计系统的层需得结合该系统的具体业务场景而定。当然,我们也要认识到层次多少的利弊:过多的层会引入太多的间接而增加不必要的开支,层太少又可能导致关注点不够分离,导致系统的结构不合理。

    我们还需要正视架构中各层之间的协作关系,打破高层依赖低层的固有思维,从解除耦合(或降低耦合)的角度探索层之间可能的协作关系。另外,我们还需要确定分层的架构原则(或约束),例如是否允许跨层调用,即每一层都可以使用比它低的所有层的服务,而不仅仅是相邻低层。这就是所谓的“松散分层系统(Relaxed Layered System)”。

    该怎么演进领域驱动架构?

    我们在上文中回顾了经典三层架构与领域驱动设计四层架构,然而任何技术结论都并非句点,而仅仅代表了满足当时技术背景的一种判断,技术总是在演进,领域驱动架构亦是如此。与其关心结果,不如将眼睛投往这个演进的过程,或许风景会更加动人。

    根据“依赖倒置原则”与 Robert Martin 提出的“整洁架构”思想,我们推翻了Eric Evans 在《领域驱动设计》书中提出的分层架构。Vaughn Vernon 在《实现领域驱动设计》一书中给出了改良版的分层架构,他将基础设施层奇怪地放在了整个架构的最上面:

    整个架构模型清晰地表达了领域层别无依赖的特质,但整个架构却容易给人以一种错乱感。单以这个分层模型来看,虽则没有让高层依赖低层,却又反过来让低层依赖了高层,这仍然是不合理的。当然你可以说此时的基础设施层已经变成了高层,然而从之前分析的南向网关与北向网关来说,基础设施层存在被“肢解”的可能。坦白讲,这个架构模型仍然没有解决人们对分层架构的认知错误,例如它并没有很好地表达依赖倒置原则与依赖注入。还需要注意的是,这个架构模型将基础设施层放在了整个分层架构的最顶端,导致它依赖了用户界面层,这似乎并不能自圆其说。我们需要重新梳理领域驱动架构,展示它的演进过程。

    那么到底该怎么演进领域驱动架构?感兴趣的同学可以在我的达人课《领域驱动战略设计实践》里了解更系统的架构知识内容。这是专门为了想提高软件架构设计能力的软件架构师量身定制的系统课程,也是是国内第一个全面讲解 DDD 的原创课程。

    本课程限时特价 39 元,共计 34 篇,形式为“图文+音频”;特价截止日期: 7月30日 。

    扫码试读或点此试读购买

    展开全文
  • 接触分层架构有段时间了,从刚开始的朦朦胧胧的理解到现在有一定深度的研究后,觉得有必要将自己的研究成果分享出来给大家,互相学习,也是对自己的一个总结。我们每天面对的项目结构可以说几乎都是分层结构的,或者...
  • 通过浏览博客园的文章发现很多朋友对分层架构特别感兴趣刚好我刚做完的毕 业设计就是专门研究.NET平台上分层架构的题目叫 基于.NET平台的分层架构与设计模 式应用研究通过做这篇论文我对分层架构有了一定的了解所以...
  • DDD中分层架构

    千次阅读 2018-04-18 16:32:59
    然而,在领域驱动设计中,层次和包的划分看起来与我们的结构又有一定区别,本文主要讨论DDD中的分层架构及每层的意义,以及与传统的三层架构的区别。 为什么要分层 软件设计中分层的设计随处可见,但是分层能带来...

    转载自https://my.oschina.net/hosee/blog/919426

    在分解复杂的软件系统时,分层是我们最常用的手段之一。然而,在领域驱动设计中,层次和包的划分看起来与我们的结构又有一定区别,本文主要讨论DDD中的分层架构及每层的意义,以及与传统的三层架构的区别。

    1. 为什么要分层
      软件设计中分层的设计随处可见,但是分层能带来什么好处呢?或者说,我们为什么要考虑分层架构呢?

    由于现实世界的复杂性,分层可以提供一个相对高层的视角来分解和简化我们的问题,此外分层也可带来可测试、可维护性、灵活性、可扩展性等方面的好处。

    简化复杂性,关注点分离,结构清晰;
    降低耦合度,隔离层次,降低依赖(上层无需关注下层具体实现),利于分工、测试和维护(可维护性);
    提高灵活性,可以灵活替换某层的实现;
    提高扩展性,方便实现分布式部署;
    看起来十分简单,好像就是把系统划分为一定的层数,并把他们堆叠组织起来。但是,当落实到具体的实践时,如何划分、各层存在的意义、如何取舍以及相应的依赖关系却并没有想象中那么容易,边界的重合部分、不同场景下关注点、层次内部的具体分解以及层次的粒度等都是我们需要考虑的问题。

    1. 什么是分层架构
      2.1 分层的历史
      最广为人知的应该就是经典的三层架构:展示层、业务逻辑层、数据访问层。

    Martin Fowler在《企业应用架构模式》中也是类似的三层进行展开的:表现层,领域层,数据源层。

    还有各种其他分层架构,这里就不一一描述了。

    面对如此多的分层架构,我们不禁思考,他们分层的依据又是什么?能否抽象出一些相同点和不同点?又该在什么时候加入哪些合适的中间层?在实践中我们又该采取怎样的架构呢?

    2.2 分层的本质
    分层其实是把一系列相同或相似的对象进行分类放在同一层,然后根据他们之间的依赖关系再确定上下层次关系。可以看出,分层的核心在于分类和关联。

    通常,我们可以将系统划分为变化较大的业务部分和相对稳定的技术部分;对于业务来说,又可划分为展示部分(前台)和内部处理逻辑(后台)两大部分;展示又可分为数据/页面部分和接口部分。如此不断的进行细分和抽象,我们可以迭代出更细粒度的分类/层次,如下所示:

    业务:需要重点关注,我们的目的也是分离出具体的业务领域逻辑:

    外部展示(表现层/接口层):数据、页面(web)、远程接口(interface/api)
    内部逻辑处理:应用逻辑(应用层/服务层)、具体业务逻辑(领域层)
    技术:相对稳定,具体业务无关(基础设施层)

    数据访问(数据访问层)
    日志、安全、异常、缓存等
    当然,分类并不唯一,基于不同的视角我们可能会有不同的分类标准。比如数据访问层也可以归类到业务相关/内部逻辑处理的部分,因为可能涉及到一些对具体业务表的操作。

    此外,根据问题领域和解决方案的复杂程度,我们可以有不同的层次。比如在业务不太复杂时,我们可以把应用层和领域层合并为一层。

    1. DDD经典分层架构
      上面我们在分析分层的本质时也提到了一些基本的层次和分类标准,但那只是一个非常粗粒度的划分。

    在实际决策时,我们需要知道各层的职责、意义以及相应的场景;而落实到代码层面时,我们还需要知道各层所包含的具体内容、各层的一些常见的具体策略/模式、层次之间的交互/依赖关系。

    首先我们来看一下Evans在《领域驱动设计》中提到的分层架构。

    问:为什么要分成这样的四层?

    分层主要目的是为了简化复杂性,系统中最复杂的部分应该就是我们的业务逻辑。当系统交互或者工作流比较复杂时,我们会考虑从业务逻辑中抽出这部分作为应用层。而各个领域内的代码则化为领域层,这样层级结构更加清晰。

    3.1 用户界面层/表示层
    用户界面层负责向用户显示信息和解释用户指令。这里指的用户可以是另一个计算机系统,不一定是使用用户界面的人。

    该层包含与其他应用系统(如web服务、RMI接口或web应用程序以及批处理前端)交互的接口与通信设施。

    它负责输入参数的解释、验证以及转换。另外,它也负责输出参数的序列化,如通过HTTP协议向web浏览器或web服务客户端传输HTML或XML,或远程Java客户端的DTO类和远程外观接口的序列化。

    可以看出,该层的主要职责是与外部用户(包括web服务、其他系统)交互,如接受用户的反馈,展示必要的数据信息。主要包含web部分和远程服务部分等。

    web部分一般包含常见的Servlet,Controller等组件,而远程接口部分主要由Facade、DTO和Assembler等构成。

    Facade:远程外观,一个粗粒度的外观,不含任何领域逻辑
    DTO:数据传输对象
    Assembler:对象组装器,负责数据传输对象与领域对象相互转换,不对外暴露
    问:参数的校验为什么在用户界面层?领域层的校验和用户界面层的校验有什么不同?

    校验应该取决于校验的内容,一般推荐尽早校验,不过这里主要是进行一些简单的、不涉及业务规则的校验。具体的业务规则的校验放在领域层。

    问:为什么需要DTO?DTO和VO是同一个东西吗?

    领域对象关系比较复杂,很难序列化,而且用户很多时候并不需要整个模型,大部分时候需要的只是其中的一部分内容,DTO可以有效减少网络调用的开销。此外,领域模型内部的逻辑也无需暴露给外部。

    DTO一般用于远程服务,如果是内部使用的话,一般可以直接使用领域对象。

    VO中有前端状态信息,比如成功失败等。

    问:为什么需要Assembler?

    主要目的是解耦,负责数据传输对象和领域对象之间的相互转换。BeanUtils也可以做到相应的功能(dozer相对好一些),不过Assembler更为清晰,安全与可控,缺点在于手工代码量稍多。

    3.2 应用层
    应用层定义了软件要完成的任务,并且指挥表达领域概念的对象来解决问题。该层所负责的工作对业务来说意义重大,也是与其他系统的应用层进行交互的必要通道。

    应用层要尽量简单。它不包含任务业务规则或知识,只是为了下一层的领域对象协助任务、委托工作。它没有反映业务情况的状态,但它可以具有反映用户或程序的某个任务的进展状态。

    应用层主要负责组织整个应用的流程,是面向用例设计的。该层非常适合处理事务,日志和安全等。相对于领域层,应用层应该是很薄的一层。它只是协调领域层对象执行实际的工作。

    综上所述,应用层是表达user case和user story的主要手段,主要用于协调领域模型与其他应用组件的工作(并不处理业务逻辑)。

    应用层中主要组件是Service,因为主要职责是协调各组件工作,所以通常会与多个组件交互,如其他Service,领域对象,Repostitory等。

    一种比较常见的做法是:应用层通常接受来自用户界面层的参数,再通过Repostitory获取到聚合示例,然后执行相应的命令操作(很薄的一层)。

    问:为什么要有应用层?

    业务比较复杂时,我们会从业务逻辑中拆分出应用层和领域层。

    如果在领域对象中事先针对具体应用的逻辑,会降低应用之间的可重用性。

    此外,如果将来需要加工作流之类的工具来实现应用逻辑,如果之前是混杂在一起的话则不好拆分。

    3.3 领域层/模型层
    领域层主要负责表达业务概念,业务状态信息和业务规则。

    Domain层是整个系统的核心层,几乎全部的业务逻辑会在该层实现。

    领域模型层主要包含以下的内容:

    实体(Entities):具有唯一标识的对象
    值对象(Value Objects): 无需唯一标识
    领域服务(Domain Services): 一些行为无法归类到实体对象或值对象上,本质是一些操作,而非事物
    聚合/聚合根(Aggregates & Aggregate Roots): 聚合是指一组具有内聚关系的相关对象的集合,每个聚合都有一个root和boundary
    工厂(Factories): 创建复杂对象,隐藏创建细节
    仓储(Repository): 提供查找和持久化对象的方法
    关于各个元素的具体含义、职责以及相关误区,可参考领域建模核心概念解析.
    对于这些具体的对象,可定义一些标准领的Annotation来规范。

    3.4 基础设施层
    基础设施层为上面各层提供通用的技术能力:为应用层传递消息,为领域层提供持久化机制,为用户界面层绘制屏幕组件。

    基础设施层以不同的方式支持所有三个层,促进层之间的通信。
    基础设施包括独立于我们的应用程序存在的一切:外部库,数据库引擎,应用程序服务器,消息后端等。

    作为基础设施层,Infrastructure为Interfaces、Application和Domain三层提供支撑。所有与具体平台、框架相关的实现会在Infrastructure中提供,避免三层特别是Domain层掺杂进这些实现,从而“污染”领域模型。Infrastructure中最常见的一类设施是对象持久化的具体实现。

    问: Repository作用是什么?和DAO的关系
    之前对Repository也曾有过误解(在我们的系统中有一个repository层位于dao和service之间)。
    DAO主要是从数据库表的角度来看待问题的,并且提供CRUD操作(只是对数据库表的一个封装),是一种面向数据处理的风格(事务脚本);
    而Repository(资源库)和Data Mapper(数据映射器)更加面向对象,通常用于领域模型中。
    因为数据访问层的暴露可能会破坏对象的封装性,对象的关系和数据一致性也难以维护,所以 应该尽量避免在领域模型中使用DAO模式,推荐使用聚合本身来管理业务逻辑。

    1. 模型的形态
      不同的架构、不同的层、不同的应用场景中有着不一样的建模需求,因此表达相同概念的模型可能会有不同的形态,例如:

    充血模型:领域模型架构中包含了领域逻辑和领域属性的领域模型。
    失血模型:传统三层架构中只有get/set方法,没有业务逻辑的POJO对象。
    贫血模型:类似充血模型,但是不包括持久化相关逻辑。
    PO(Persistant Object):持久化对象,即DAO从JDBC取出来的对象。传统三层架构中,PO即POJO组件中的对象,存在于DAO和Service之间。
    DO(Domain Object):领域对象,领域模型架构中,PO从数据库取出来后,有一个“重建”的概念,即根据数据还原实体,这个被还原的实体就是DO,存在于DAO和Service之间。
    DTO(Data Transfer Object):数据传输对象。对传统三层架构来说,该对象存在于Service和Controller之间。PO到DTO的转换可以在Service或Controller中实现。
    VO(View Object):视图对象。Controller在返回DTO给视图时,可能还需要包括状态信息例如操作成功/失败的状态码、提示文本等。这时就需要在DTO外面再包一层,即View Object。该对象存在于Controller和Web之间,由Controller进行装配

    展开全文
  • 软件体系结构 Zhenyan Ji Beijing Jiaotong University 分层架构 架构风格 分层系统 分层系统 构件: 层 连接器层间的交互协议 分层架构 分层架构 每层提供一组相关的服务; 每层只使用下面的层 展示层 1.如果任意一层...
  • Blank-Project:分层架构
  • 分析了工厂模式的特点,阐述了分层架构体系的设计思路。以数据访问层的设计为例,从设计模式的角度探讨了可复用的数据访问层的实现方法,并重点分析了工厂模式的具体应用过程。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 126,907
精华内容 50,762
关键字:

分层架构