架构设计--逻辑层 vs 物理层

如果你对项目管理、系统架构有兴趣,请加微信订阅号“softjg”,加入这个PM、架构师的大家庭


Layer
和Tier都是层,但是他们所表现的含义不同,Tier指的是软件系统中物理上的软件和硬件,具体指部署在某服务器上,而Layer(逻辑层)指软件系统中完成特定功能的逻辑模块,逻辑概念。

Layer是逻辑上 组织代码的形式。比如逻辑分层中表现层,服务层,业务层,领域层,他们是软件功能来划分的。并不指代部署在那台具体的服务器上或者,物理位置。

Tier这指代码运行部署的具体位置,是一个物理层次上的划为,Tier就是指逻辑层Layer具体的运行位置。所以逻辑层可以部署或者迁移在不同物理层,一个物理层可以部署运行多个逻辑层。

从Layer和Tier就会延伸到逻辑架构和物理架构。我们一个逻辑分层(N-Layer)的部署运行环境可以在一台或者是多台服务器,由于物理环境的多样性,逻辑层次的部署也具有多样性。这就需要我们必须了解物理架构和逻辑架构。

大多数情况下我们所说的N层应用系统指的是物理模型,具体模块的分布物理位置。客户端,服务层,逻辑层,数据库服务器,与我们的逻辑模型之间并不是一对一的关系。逻辑上的分层架构与物理位置上的服务器数量和网络边界多少无关,逻辑架构层次只与我们的功能划分相关,是按照功能划分。经典的3-Layer架构:表现层,业务层,数据访问层,他们可能运行在同一物理位置上。也可以是3台计算机上,这并不是逻辑架构所关注的。逻辑层次和物理分层数量关系为:逻辑层数必须不小于物理层数,因为一个物理层可以部署一个或者多个逻辑层次,逻辑层次只能迁移在不同的物理环境。

逻辑层次的架构能帮助我们解决逻辑耦合,达到灵活配置,迁移。

一个良好的逻辑分层可以带来:

  1. 逻辑组织代码

  2. 易于维护

  3. 代码更好的重用

  4. 更好的团队开发体验

  5. 代码逻辑的清晰度

一个良好的物理架构可以带来:

  1. 性能的提升

  2. 可伸缩性

  3. 容错性

  4. 安全性

逻辑层次越多会影响程序运行的性能,但代码层次的低耦合,松散化,是需要架构师的权衡的,我觉得一般应用程序的瓶颈并不在这里。

如果你对项目管理、系统架构有兴趣,请加微信订阅号“softjg”,加入这个PM、架构师的大家庭

架构设计--逻辑层 vs 物理层,布布扣,bubuko.com

时间: 2024-08-05 02:36:30

架构设计--逻辑层 vs 物理层的相关文章

系统架构师-基础到企业应用架构-业务逻辑层

一.上章回顾 上章我们主要讲述了系统设计规范与原则中的具体原则与规范及如何实现满足规范的设计,我们也讲述了通过分离功能点的方式来实现,而在软件开发过程中的具 体实现方式简单的分为面向过程与面向对象的开发方式,而目前更多的是面向对象的开发设计方式.并且我们也讲述了该如何通过设计手段去分析功能点及设计分离 点,应该如何在设计的过程中分析的角度及如何去满足设计规范与原则.首先我们通过下图来回顾下上章要点: 二.摘要 本文将已架构的方式去分析分层结构中的业务层的设计,如何写出来内聚度,高耦合的业务逻辑层

架构模式逻辑层模式之:表模块(Table Model)

表模块和领域模型比,有两个显著区别: 1:表模块中的类和数据库表基本一一对应,而领域模型则无此要求: 2:表模块中的类的对象处理表中的所有记录,而领域模型的一个对象代表表中的一行记录: 一般情况下,我们可以基于第二点来严格区分你的设计是表模块的,还是领域模型的.如:如果我们有许多订单,则领域模型的每一个订单都有一个对象,而表模块只有一个对象来处理所有订单(注意,这里的类,都是指业务逻辑层的类,而不是实体类.表模块的类的对象和常规的领域模型的对象很类似,但是关键区别是:它没有标识符来标出它所代表的

架构/设计

随笔分类 -架构/设计 软件架构设计模式简述 2014-03-25 20:33 by 破狼, 2465 阅读, 收藏, 编辑 在软件开发设计中我们经常会面对业务分析,提取领域问题,从而实现软件架构设计.关于 软件架构设计Martin Fowler在2004出版的<企业应用架构模式>中 概括了四种方式的架构模式.它们分别为事务性脚本,表驱动模式,活动记录模式,领域驱动设计.前两者事务性脚本,表驱动模式作为 面向过程方式架构设计,后两者为面向对象架构设计.它们适合于不同的业务场景,它们也各有长短.

系统架构师-基础到企业应用架构-数据访问层

一.上章回顾 上篇我们简单讲述了服务层架构模式中的几种,并且讲解了服务层的作用及相关的设计规范,其实我们应该知道,在业务逻辑层中使用领域模型中使用服务层才 能发挥出最大的优势,如果说我们在业务逻辑层还是使用非领域模型的模式话,服务层的作用仅体现在解耦作用.其实在业务逻辑层采用领域模型时,我们前面说的持 久化透明的技术,其实我们可以通过服务层来做,我们在服务层中处理领域对象信息的持久化操作.当然本篇可能不会深入讨论持久化透明的具体实现,后面会单独开 篇来讲述,我们先来回顾下上篇讲解的内容:  上图

软件设计入门1 架构设计

热爱编程才能做优秀的软件设计师! 软件设计有一些方法可以参考.但更重要的是要有好的需求分析.丰富的技术知识和设计经验(多动手!)不断追求更好的精神(多动脑!). 遇到别人的系统想一下自己能否实现,如何实现? 一.优秀设计的标准:性价比高的设计. 1)优秀的设计都是需求驱动的,不熟悉需求就做出来的设计是不靠谱的: 2)优秀的设计应该是当前团队能理解能实现的,太超前的设计项目团队做不出来,这个设计只能是摆设: 3)优秀的设计应充分考虑当前各种限制条件,适当做出平衡,能保证达成项目的目标: 4)优秀的

架构设计-业务逻辑层简述

如果你对项目管理.系统架构有兴趣,请加微信订阅号"softjg",加入这个PM.架构师的大家庭 业务逻辑层是专门处理软件业务需求的一层,处于数据库之上,服务层之下,完成一些列对Domain Object的CRUD,作为一组微服务提供给服务层来组织在暴露给表现层,如库存检查,用法合法性检查,订单创建. 业务逻辑层包含领域对象模型,领域实体,业务规则,验证规则,业务流程.1:领域对象模型为系统结构描述,包含实体功能描述,实体之间的关系.领域模型处于天生的复杂性:2:领域实体:业务层是一些操

[架构设计] 什么是业务逻辑

讨论设计时,专业词汇满天飞,每个人的技术背景.工作经验上的不同都会导致在理解上存在着差异.无论是SEI的定义.OMG UML的定义.还有各路大神的定义,都有从不同视角带来的差异.准备后面关注这些定义的差异,摊开来大家一起来讨论. 关于'业务逻辑', 国内国外争论了很多年了(这篇在07年就说没有清晰的定义),其中几个比较详细的讨论见附录(一定要看评论).我总结主要分为两类: 一类是逻辑处理论,一类是数据操作论. 逻辑处理论 先看前者,这一类观点,核心是强调逻辑.细说业务逻辑中,作者将业务逻辑分别做

关于项目中的DAL数据接入层架构设计

摘要:项目中对关系型数据库的接入再寻常不过,也有海量的ORM工具可供选择,一个一般性的DAL数据接入层的结构却大同小异,这里就分享一下使用Hibernate.Spring.Hessian这三大工具对DAL层的具体实现方法,也是对之前使用的一个总结. 关键词:Hibernate, Spring, Hessian, DAL, 数据接入层, 架构设计 注意:以下配置或代码运行在Hibernate4.2.5,Spring3.2.4,Hessian4.0.37,Tomcat7.0.47环境下 一.Mode

PHP业务逻辑层和数据访问层设计

以下还是觉得有点抽象 1.面向对象能给我们什么? 进行分析之前,我们先来复习一下面向对象.对象是要进行研究的任何事物.类是具有相同或相似性质的对象的抽象.面向对象的要素:封装.继承.多态.面向对象目的是:如何分配职责. 面向对象设计原则: 单一职责原则 (SRP) 一个类,只有一个引起它变化的原因. 开放-封闭原则 (OCP)(对外)可扩展,(对内)不可修改. 李氏替换原则 (LSP) 子类型必须能够完全替换其父类型. 依赖倒置原则 (DIP) 要依赖于抽象,不要依赖于具体. 接口隔离原则 (I