事务脚本-领域模型

  

Martin Fowler定义是:
  事务脚本,将所有逻辑组织在一个单一过程,进行数据库直接调用,每个业务请求都有自己的事务脚本,并且是一个类的公开方法。
  领域模型,是一系列相互关联的对象,每个对象代表一定意义的独立体,既可以一起以一种大规模方式协作;也可以小到以单线方式运行。

  事务脚本总体来说:就像直奔主题,平铺直叙,就功能谈功能,直接没有回旋余地;领域模型给人感觉好像肚子里就那么点货而领域模型则象是文人骚客,上了一个档次,会使用美妙表达方式,有余地。
比如唐诗:清明时节雨纷纷,路上行人欲断魂;借问酒家何处有,牧童遥指杏花村;这是领域模型描述方式,如果采取事务脚本方式就是:清明我很伤心,伤心要喝酒。

  事务脚本同样用类,却并不是真正的面像对象:很多人也在用类,也在使用模式,但是他们的思维一样是面向过程的,因为他们的世界中除了过程就不存在任何东西了,它们俩如何来区分呢?其实还是面向过程与面向对象的分别:
  事务脚本:围绕功能,以功能为中心。
  领域模型:描述领域类,以类之间的协作完成所需功能。

  我理解的事物脚本与领域模型的区别是,类是死的还是活的。
  事物脚本模式本质还是面向过程编程,尽管定义了很多类来将分层业务逻辑,但是定义的类是死的,机械的,就好比机器人,没有自己的状态,就是为了功能而生,固定的输入进去,固定的输出出来。

  领域驱动模式本质是一些类协同工作,是面向对象编程,就好比活生生的人,有自己的状态,行为,一群人相互协同工作。 
 
  如果项目太小,两者不好区分,比如,功能太简单:送快递,让机器人,还是活生生的人完成这个业务,结果都是相同的,所以功能的复杂度太 
小,两者没有太大的区别。
  事物脚本虽是面向过程编程,但是略带有面向对象色彩,就像机器人,还是太机械死板,缺少了一种作为人的鲜活感。
  领域驱动虽是面向对象编程,但是其实还是有过程的(任何逻辑都是有过程的),但是这时不在以过程为主,增强了对象的主观性,就感觉是工作不在是为了完成事业赢得巨大成就,而是为了满足人类的幸福感责任感。

  引用:http://www.jdon.com/34056    领域模型VS事务脚本

时间: 2024-08-09 06:35:04

事务脚本-领域模型的相关文章

事务脚本

本文摘抄自<.NET企业级应用架构设计> 业务逻辑层的模式的发展历史 历史上,事务脚本是第一个广泛应用的业务逻辑模式. 后来出现了基于表数据的表模块模式,仍然属于过程式模式,但是加入了一些面向对象思维. 在面向对象开发兴起之后,出现了基于对象的业务逻辑模式,最简单的对象模型就像是数据库表的数据模型,这里的对象就是数据库中的记录,并加了一些额外的方法,这种模式通常叫做活动记录模式. 随着业务逻辑的复杂性越大,软件的抽象程度越高,这时就应该从领域着眼,创建一个领域驱动的对象模型,这种模式通常叫做领

.NET应用架构设计—表模块模式与事务脚本模式的代码编写

阅读目录: 1.背景介绍 2.简单介绍表模块模式.事务脚本模式 3.正确的编写表模块模式.事务脚本模式的代码 4.总结 1.背景介绍 要想正确的设计系统架构就必须能正确的搞懂每个架构模式的用意,而不是胡子眉毛一把抓.现在有一个现象是什么呢,项目的结构从表面上看是很不错,层分的很合理,其实对业务系统来说也就那么几种层设计方法,但是现在很多项目的逻辑架构的设计不是理想,有很多概念大家并不是很了解,当然也许每个人对技术的追求不同罢了.不管你追求不追求,事实我们还是要去往正确的方向努力才对的. 很多人包

PHP面向对象之事务脚本模式

/* 事务脚本模式: 类似于thinkphp中的model层,或者说就是操作数据库的类. 个人觉得实践中使用起来还是挺简单方便的,就是SQL语句写死了的话,灵活性就不够. 示例代码如下: */ namespace woo\process; abstract class Base{ static $DB; //pdo对象 static $stmts = array(); //sql语句句柄 function __construct (){ $dsn = \woo\base\ApplicationR

你在用什么思想编码:事务脚本 OR 面向对象?

最近在公司内部做技术交流的时候,说起技能提升的问题,调研大家想要培训什么,结果大出我意料,很多人想要培训:面向对象编码.于是我抛出一个问题:你觉得我们现在的代码是面向对象的吗?有人回答:是,有人回答否.我对这个问题的回答是:语法上,是了,但是架构上或者思想上,不是.我们现在的大部分代码,如果要死扣一个名词的话,那就是:事务脚本. 1:最开始的事务脚本 在 Martin Fowler 的书中,存在一个典型的 应用场景,即"收入确认"(Revenue Recognition).该"

监控MySQL长事务脚本

监控长事务的脚本 #!/bin/bashmysql -N -uroot -p'密码' -e "select now(),(UNIX_TIMESTAMP(now()) - UNIX_TIMESTAMP(a.trx_started)) diff_sec,b.id,b.user,b.host,b.db,d.SQL_TEXT from information_schema.innodb_trx a inner join information_schema.PROCESSLIST b on a.TRX_

Oracle 查看 使用 UNDO 段的事务脚本

查看oracle undo segment段的信息: SELECT T1.USN, T2.NAME, T1.STATUS, T1.LATCH, T1.EXTENTS, T1.WRAPS, T1.EXTENDS FROM V$ROLLSTAT T1, V$ROLLNAME T2 WHERE T1.USN = T2.USN; 检查事务使用undo segment的情况: SELECT s.username, s.sid, pr.PID, s.OSUSER, s.MACHINE, s.PROGRAM,

领域模型(domain model)&amp;贫血模型(anaemic domain model)&amp;充血模型(rich domain model)

领域模型是领域内的概念类或现实世界中对象的可视化表示,又称为概念模型或分析对象模型,它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系. 贫血模型是指使用的领域对象中只有setter和getter方法(POJO),所有的业务逻辑都不包含在领域对象中而是放在业务逻辑层.有人将我们这里说的贫血模型进一步划分成失血模型(领域对象完全没有业务逻辑)和贫血模型(领域对象有少量的业务逻辑),就不对此加以区分了. 充血模型将大多数业务逻辑和持久化放在领域对象中,业务逻辑(业务门面)

什么是领域模型(domain model)?贫血模型(anaemic domain model) 和充血模型(rich domain model)有什么区别

http://blog.csdn.net/helloboat/article/details/51208128 领域模型是领域内的概念类或现实世界中对象的可视化表示,又称为概念模型或分析对象模型,它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系.贫血模型是指使用的领域对象中只有setter和getter方法(POJO),所有的业务逻辑都不包含在领域对象中而是放在业务逻辑层.有人将我们这里说的贫血模型进一步划分成失血模型(领域对象完全没有业务逻辑)和贫血模型(领域对象

微服务业务开发三个难题-拆分、事务、查询(上)

微服务架构变得越来越流行了.它是模块化的一种方法.它把一整块应用拆分成一个个服务.它让团队在开发大型复杂的应用时更快地交付出高质量的软件.团队成员们可以轻松地接受到新技术,因为他们可以使用最新且推荐的技术栈来实现各自的服务.微服务架构也通过让每个服务都被部署在最佳状态的硬件上而改善了应用的扩展性. 但微服务不是万能的.特别是在 领域模型.事务以及查询这几个地方,似乎总是不能适应拆分.或者说这几块也是微服务需要专门处理的地方,相对于过去的单体架构. 在这篇文章中,我会描述一种开发微服务的方法,这个