关于软件的任务到底是什么的思考

简介: 原文:关于软件的任务到底是什么的思考阅读本文需要有DDD,DCI的知识背景。 首先,我觉得软件是用来被用户使用的,也就是说软件是用来帮用户完成一些事情的。从下面的用例图可以很好的理解用户与软件的关系:   上图是超市里的一个营业员处理一笔销售的一个用例。
原文: 关于软件的任务到底是什么的思考

阅读本文需要有DDD,DCI的知识背景。 首先,我觉得软件是用来被用户使用的,也就是说软件是用来帮用户完成一些事情的。从下面的用例图可以很好的理解用户与软件的关系:

 

上图是超市里的一个营业员处理一笔销售的一个用例。从这个用例我们可以清楚的看到营业员和系统之间的一个交互。从中我们可以清晰的得出系统该做什么:

makeNewSale
enterItem
makePayment

这三个操作可以理解为用户希望软件为她做的三件事请。最近我惊奇的发现,DDD和DCI的一个巨大差别,让我不得不拿出来和大家确认。那就是:

1)DDD强调软件不应该实现整个用例的交互过程,而应该只建立一个排除软件使用者的领域模型,该领域模型的目的不是要实现软件软件使用者与模型之间的交互过程,而是要捕捉和实现软件使用者提出的需求;
2)DCI强调软件应该实现整个用例的交互过程,在DCI的架构中,可能会有一个Person对象,然后扮演Cashier的角色参与到MakeNewSale或EnterItem等场景中去。
 
大家看到区别了吗?DDD更多的是把软件或者说把领域模型看成是一个“工具”,我们人类作为软件使用者通过使用这个工具来做一些事请;而DCI则是在模拟软件使用者与软件之间的整个交互过程,也就是说在DCI的架构中,我们能在内存中看到一个Cashier在做事情,就像现实生活中一样;而在DDD中,我们只会在内存中看到一些“物”在相互作用帮助软件使用者处理一些事情;简单的说:DCI是在完全模拟现实,而DDD则只侧重于表达除人之外的一个客观的“物模型”;

个人认为DDD的思想要比DCI好,因为虽然通过DDD思想建立出来的领域模型看起来是静态的,但我认为这恰恰是软件本质上该做的并且是只需要做的事情,事实上,我们都认为电脑是工具,我们建立领域模型目的也是为了用它,把它看成为一个工具而已。如果软件还要模拟人际交互的过程,那无疑会使软件(领域模型)不具有客观性。

其实很多时候想想,如果基于贫血模型的开发,那么软件只是一个帮助人类记录事实的工具,我们设计的对象没有任何行为,只是数据,就像数据库中的数据一样。事实上,数据库里存放的不是数据,而是事实的结果。比如数据库中有一条应聘记录,表示某个人在某个时候应聘过某个职位这个事实。所以,在贫血模型的开发模式下,我们的软件仅仅只是帮助我们记录事实的结果;
 
而在DDD等倡导的充血模型的开发模式下,对象不仅仅只是一个记录事实结果的工具,而是一个个活生生的能够拥有自己个体行为以及能够和其他对象交互的交互行为的对象。此时,对象不仅可以记录事实结果,而且可以表示事实发生的原因,即对象之间的相互交互协作,即这个事实结果是通过怎样的事实产生的,其实从更高的层面上理解,对象之间交互是一种正在发生的事实。因此,基于DDD思想的对象不仅可以表示事实的结果,还能表示事实本身,即对象交互。但这个交互没有包含软件使用者与软件之间的交互,而仅仅表示软件领域模型中各个具有一定客观性的对象之间的交互;
 
而在DCI的思想架构下,则认为软件除了要记录DDD所涉及的事实外,还应该表示出软件使用者与软件之间的整个交互事实;
 
那么大家觉得哪个才是软件需要实现的真谛呢?呵呵,就这么多吧,话不多,但都是我深刻思考后的东西。希望大家也谈谈各自的看法。 
目录
相关文章
|
10天前
|
监控 安全 Android开发
雇佣间谍软件有多普遍?超乎你的想象
雇佣间谍软件有多普遍?超乎你的想象
sbs
|
SQL Oracle 关系型数据库
软件需求工程
前言之前看过一些系统分析相关,偏信管、软工专业的书:《系统分析与设计方法》,《软件需求》。 需求工程 部分对实际开发工作有不少帮助。相信很多开发也不太了解信管或者软工,更多关注于具体领域的前沿技术,所以这些概念应该能用到。文中部分是引用书中原文,部分是个人观点。文中产品,软件,系统是类似的含义。2020.7.10 —— by zz。需求需求一词的字典义是“被命令或强制性的东西;需要或者必要”,和软
sbs
625 1
软件需求工程
《软件需求工程(第2版)》一导读
许多人经过研究发现,当软件开发项目失败时,软件需求问题通常正是核心问题。因此,在软件开发过程中,必须极早和有效地发现和解决与软件需求相关的问题。
1186 1
|
项目管理
艾伟也谈项目管理,谈软件协作:君子和而不同,小人同而不和
我们知道现在的软件开发最大的问题就是变化,其实这也不是软件本身的问题,我更觉得是软件的特点。因为他不像建筑,画个建筑图,一般不会偏到哪里去。然而很多需要软件的人,他可能希望软件能达到什么目的,至于具体是什么样子,他自己也不知道。
2742 0
|
Oracle 关系型数据库 Java
论细节决定成败
说明 近期,工作中、工作外、个人、他人均遇到了不少问题,而这些问题的成因均因未注意细节而造成,使我再一次想起那句名言:细节决定成败。于是我觉得很有必要做一个记录,用以自警和他警。 事件一:一个数据库预留字段造成的上线失败 这个事其实是比较严重的一个事,因为涉及到了生产,并严重影响甲方公司对我方的评价。
1850 0
《代码之殇》(原书第2版)——第2章 过程改进,没有灵丹妙药 2005年4月1日
本节书摘来自华章出版社《代码之殇》(原书第2版)——第2章 过程改进,没有灵丹妙药,2005年4月1日,作者:(美 )Eric Brechner 著 林锋 译.更多章节内容可以访问云栖社区“华章计算机”公众号查看。
1387 0
|
测试技术
《代码之殇》(原书第2版)——第2章 过程改进,没有灵丹妙药 2007年10月1日
本节书摘来自华章出版社《代码之殇》(原书第2版)——第2章 过程改进,没有灵丹妙药,2007年10月1日,作者:(美 )Eric Brechner 著 林锋 译.更多章节内容可以访问云栖社区“华章计算机”公众号查看。
998 0
|
测试技术
《代码之殇》(原书第2版)——第2章 过程改进,没有灵丹妙药 2011年2月1日
本节书摘来自华章出版社《代码之殇》(原书第2版)——第2章 过程改进,没有灵丹妙药,2011年2月1日,作者:(美 )Eric Brechner 著 林锋 译.更多章节内容可以访问云栖社区“华章计算机”公众号查看。
1322 0
|
测试技术 项目管理 数据库
《代码之殇》(原书第2版)——第2章 过程改进,没有灵丹妙药 2010年10月1日
本节书摘来自华章出版社《代码之殇》(原书第2版)——第2章 过程改进,没有灵丹妙药,2010年10月1日,作者:(美 )Eric Brechner 著 林锋 译.更多章节内容可以访问云栖社区“华章计算机”公众号查看。
1493 0

热门文章

最新文章