一起谈.NET技术,.NET企业级架构解决方案:业务层

  引言

  Martin Fowler说过:“任何人都可以写出计算机才能理解的代码,只有写出人能理解的代码的程序员才是好程序员。”

每一个复杂的软件都应该按层来组织。每一层代表系统的一个逻辑部件。尤其是,业务层的模块包括了所有使得系统运行的时候和其它层交互所需要的功能算法和计算,其他层包括数据访问层DAL和表现层。

  业务层是任何分层系统的神经中心,包含了大部分的核心逻辑。因为这个原因,它也经常被叫做:业务逻辑层BLL。

  正文

  1、业务逻辑层是什么

  抽象的讲,业务逻辑层是系统的一部分,用来处理和业务相关的任务。本质上,业务逻辑层包括一系列执行数据的操作。数据被模型化为问题域的实体,例如:发票、用户、订单、清单。另一方面,包括一些操作,例如:创建一个发票,添加一个用户,处理一个订单。

  2、剖析业务层

  如果你从纵向来看业务逻辑层,你会发现一些业务模型的实体,表达用户策略和需求的业务规则,实现自动化功能的服务,定义文档和数据从一层流转到一层的工作流。

  安全是一个在所有层都需要考虑的严重问题,但是在业务逻辑层,代码扮演一个用户界面层的守门人。在业务逻辑层的安全是以角色为基础的,或者是限制对业务对象的访问,只对授权用户开放。

  2.1领域对象模型

  领域对象模型更倾向于对整个系统提供一个结构化的视图,包括实体的功能描述,实体间的关系,实体的职责。模型产生于用户需求,使用UML的用例图和类图进行文档化。在模型中,你表示出用来存储数据和暴露操作的真实世界元素。每一个实体代表模型中的一个角色,提供一些行为。每个实体都有自己的职责,依据领域的关系进行交互。

  很多应用被打上复杂的标记,实际上,如果你看到最终的技术实现,你会发现是相对简单的。但是,整体来看这个应用是复杂的,那是因为领域内在的复杂性。通常来说,困难在于构建一个适当的软件模型,而不是最终的实现。一个设计良好的模型,无论你运行到哪里,可以解决任何难度的复杂性。

  对象模型和领域模型

  为了清晰起见,让我们确定一下“对象模型”和“领域模型”这两个词。尽管我们经常会交替使用,实际上他们代表不同的事物,就算代表同一个事物的时候,他们的抽象级别也是不同的。我们所谓的“对象模型”就是简单的对象图。对于如何设计和实现模型没有限制。如果你有了一些相互关联的类,就有了一个对象模型。就像你看到的,描述相当通用,适用于大部分的解决方案。

  我们所谓的“领域模型”就是另外一回事了。领域模型是用来满足一系列需求的对象模型。典型的,领域模型中的类没有持久层的概念,是一种与其他帮助类库中的类没有关系的理想状态。另外,领域模型设计用来解决特定的领域问题,试图从实体和它们之间的关系来抽象业务流程和数据流。

  记住领域模型也是一种特殊的设计模式,在后面我们会讨论。

  2.2 领域实体

  从外部来看,业务逻辑层就是对业务对象的一系列操作。大多数情况,一个业务对象就是一个领域实体的实现,也就是一个封装了数据和行为的类。也可能是一些实现特殊计算的辅助类。业务逻辑层决定业务对象之间如何交互。它也为参与交互的模块、业务对象强加了一些规则和流程。

  业务逻辑层处在一个分层系统的中间,和表现层、数据访问层交换信息。业务逻辑层的输入和输出不是非要业务对象不可。在大多数情况,架构师更倾向于在跨层之间使用DTO(Data Transfer Objects)进行数据传输。

业务对象和数据传输对象有什么不同呢?

  业务对象包含数据和行为,在业务逻辑中可以看做是充血的活动对象。数据传输对象只是一个值对象,是包含数据没有附加的行为。处于序列化的目的,在业务对象中存储的数据需要被序列化到数据传输对象中。数据传输对象除了setter和getter以外没有逻辑行为。在模型中,每一个领域实体类可能会对应多个数据传输对象。为什么是多个数据传输对象呢?

  一个数据传输对象不是一个无行为的领域对象的简单副本。相反,一个数据传输对象代表一个在特定上下文环境使用的领域对象的子集。例如:在一个方法中,你需要一个只有Name和ID的CustomerDTO;其他地方你可能需要一个有Name、ID、Country、Contract的CustomerDTO。通常来说,一个领域对象是一个包含很多对象的图,例如:Customer包含orders,orderdetails,等等。

  重点

  关于DTO和OB的协同使用,可以引出一大串的、无意义的争论。理论建议在任何情况下都是用DTO来减少层之间的耦合。实践中,经常会提醒我们已经够复杂的了,尽量避免不必要的附加东西。作为一条实践的准则,我们建议在处理少于100个业务对象的模型的时候,你不需要这么做。在这些情况下,DTO和OB很可能很相似。

  2.3 业务规则

  在现实世界中的组织都是基于一系列的业务规则组成的。你可以争论这些规则的级别,但是不可以否认这些规则的存在。每一个组织都有追求的战略,规则是实现战略的主要规范。战略指明了要达到的高度,规则明确了如何达到这个高度。

规范业务规则有各种方式。如果你生活和工作在一个完美的世界,每一个组织维护他自己的规则数据库,这样在一个项目中的各个团队中就很容易共享这些规则。大多数情况不是这样的,搜集业务规格的过程开始于开发项目。结果就是,业务规则在项目快要结束的时候才整理出来,而且是在架构师之间共享。

时间: 2024-09-29 01:12:01

一起谈.NET技术,.NET企业级架构解决方案:业务层的相关文章

.NET企业级架构解决方案:业务层

引言 Martin Fowler说过:"任何人都可以写出计算机才能理解的代码,只有写出人能理解的代码的程序员才是好程序员." 每一个复杂的软件都应该按层来组织.每一层代表系统的一个逻辑部件.尤其是,业务层的模块包括了所有使得系统运行的时候和其它层交互所需要的功能算法和计算,其他层包括数据访问层DAL和表现层. 业务层是任何分层系统的神经中心,包含了大部分的核心逻辑.因为这个原因,它也经常被叫做:业务逻辑层BLL. 正文 1.业务逻辑层是什么 抽象的讲,业务逻辑层是系统的一部分,用来处理

一起谈.NET技术,NGuestBook架构体系及实现指南

      前几天我在我的Blog上发布了NGuestBook(点击这里下载),得到了很多反馈,在这里非常感谢大家的关注和支持.一些朋友在E-mail中提到,这个NGuestBook和我那个系列文章<基于.NET平台的分层架构实战>中讲的Demo有非常多不一样的地方,问我能不能单独写一篇文章说明一下这个新NGuestBook的架构方式和实现相关的问题.      所以我专门写下这篇文章,对这个NGuestBook的架构体系和实现进行一个简要的说明,希望本文的内容能对大家有所帮助.      有

一起谈.NET技术,系统架构技能之设计模式—代理模式

一.上篇回顾 很久没有更新设计模式系列的文章了,有了很多热心朋友的反馈,我决定继续将这个系列赶快写完,最近由于过年了,有很多相关的事宜要做,所以没有时间来写,也是对大家的说下抱歉,感觉写文章的时间越来越少了,不过我会努力,尽快将这个系列写完,与大家共勉,希望大家有什么意见或建议,都可以帮我提出来,我好改进,谢谢!. 本文主要是讲述设计模式中的结构性模式中的最后一个本系列讲述的模式,也是经常用到的模式,代理模式,由于目前我们在很多的技术中都会用到这个代理模式,所以对我们来说,代理模式是必须掌握的模

云上技术架构和业务架构的进化之路——阿里云Serverless的解决方案

本文PPT来自高级专家承宗于10月16日在2016年杭州云栖大会上发表的<云上技术架构和业务架构的进化之路--阿里云Serverless的解决方案>. 目前软件开发规模日趋庞大,在软件研发与运维经常会遇到许多挑战.这些挑战主要包括六点:1.随着新旧业务一起发展,老的软件架构越来越复杂,软件与硬件的管理运维复杂度指数增长 2.为应用增加新功能的周期越来越长 3.复杂的业务模式下,硬件采购的估算成为世界难题,拍脑袋成为常态 4.老的硬件和软件需要被淘汰,业务永续出现巨大风险 5.系统架构中由于各种

一起谈.NET技术,.NET 分布式架构开发实战之二 草稿设计

前言: 本篇之所以称为草稿设计,是因为设计的都是在纸上完成的.反映了一个思考的过程. 本篇的议题如下: 1) 第一个数据层草图的提出 2) 对数据访问层的思考 3) 第二个数据层草图的提出 1.数据层草图的提出 Richard开始着手设计,一开始他没有就立刻在自己的计算机开始敲代码.而且采用笔+纸开始构思. 因为他认为:写程序不是什么时候都得上机,脑子里面想什么的才是最重要的,往往很多时候,在设计程序时,首先在头脑中就已经把整个功能已经实现了,甚至代码的详细编写都已经在头脑中走了一遍,并且在头脑

一起谈.NET技术,我眼中的Visual Studio 2010架构工具

影响架构质量的是构建体系架构的思想.原则.实践与架构师的经验,绝不是工具.即使是最优秀的架构工具,也不可能像倚天宝剑一般--倚天一出,谁与争锋--似乎谁握住了这把利刃,就能够成为武林盟主.架构工具可以改善架构师的工作,却不能替换架构的过程.软件开发过程中,最重要的依旧是人. 我在尝鲜Visual Studio 2010架构工具[i]时,偶然看到一篇文章,用夸张的语言吹捧VS 2010架构工具,认为它是架构师最怕程序员知道的新工具.这让我有感而发,我想起数十年前甚嚣尘上的一个理论,那就是CASE工

云计算技术融合下的SOA架构解决方案

随着SOA(Service Oriented Architecture,面向服务的架构)和云计算的迅速发展,各类企业都面临着此项技术发展所带来的巨大挑战和机遇.众多企业技术架构都纷纷转向SOA或与其它架构混合构建的模式,提供充分利用云交付的服务.其中,云计算模式是重要的一个合作架构,云计算提供商在网上创建了巨大的资源,企业可以利用这些架构充分利用资源.IT已经成为业务转变时滞后的部分.为解决此问题,先后进行了结构化计算的变革.面向对象的变革.分布式对象.组件开发.企业资源规划.客户关系管理,最终

一起谈.NET技术,走向ASP.NET架构设计——第五章:业务层模式,原则,实践(前篇)

在上一章中,我们讲述了有关业务层分层的一些知识,下面我们就来看看,在具体的业务层的设计中,我们可以采用哪些模式可以将业务层设计的更加的灵活! 架构模式 首先我们就来看看,如何更加有效的组织业务规则. Specification Pattern(需求规格模式) 这个模式的使用方法就是:把业务规则放在业务类的外面,并且封装成为一个个返回boolean值的算法.这些一个个的业务规则的算法不仅仅便于管理和维护,并且还可以被重用,而且很方便的组织成为复杂的业务逻辑. 下面我们就来看一个以在线租DVD的公司

一起谈.NET技术,走向ASP.NET架构设计——第四章—业务层分层架构(中篇)

在上一篇文章中,我们讨论了两种组织业务逻辑的模式:Transaction Script和Active Record.在本篇中开始讲述Domain Model和Anemic Model. Domain Model 在开发过程中,我们常常用Domain Model来对目标的业务领域建模.通过Domain Model建模的业务类代表了目标领域中的一些概念.而且,我们会看到通过Domain Model建模的一些对象模拟了业务活动中的数据,有的对象还反映了一些业务规则. 我们就来看看电子商务系统的开发,在