本文主要是介绍关于软件的任务到底是什么的思考，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
摘自http://www.jdon.com/43127
首先，我觉得软件是用来被用户使用的，也就是说软件是用来帮用户完成一些事情的。从下面的用例图可以很好的理解用户与软件的关系：
上图是超市里的一个营业员处理一笔销售的一个用例。从这个用例我们可以清楚的看到营业员和系统之间的一个交互。从中我们可以清晰的得出系统该做什么：
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 所涉及的事实外，还应该表示出软件使用者与软件之间的整个交互事实；
那么大家觉得哪个才是软件需要实现的真谛呢？
呵呵，就这么多吧，话不多，但都是我深刻思考后的东西。希望大家也谈谈各自的看法。
2011年11月02日 22:50 "@tangxuehua "的内容
DDD强调软件不应该实现整个用例的交互过程，而应该只建立一个排除软件使用者的领域模型，该领域模型的目的不是要实现软件软件使用者与模型之间的交互过程，而是要捕捉和实现软件使用者提出的需求；
2）DCI强调软件应该实现整个用例的交互过程，在DC ...
2）DCI强调软件应该实现整个用例的交互过程，在DC ...
首先，你总结得非常好，这是我以前一直在强调的，DDD重视的是静态结构，就像结构型模式一样；而DCI 重视的动态交互，是行为模式；DDD对应的是UML中类图实现；DCI对应的是UML中用例图实现。
DDD各有侧重点，但是不代表谁比谁好，他们都是盲人摸象，反映事物的一个方面，正如我们要完整表达一个需求，需要类图 + 用例图 + 顺序图结合起来表达一样，而四色 原型的类图其实是原始类图 + 顺序图，将动静结合在一起了。
DDD是找出静态实体核心，因为在一个领域中如果没有实体，我们就没有DCI 里面发生的任何场景，如果没有电话，就不会有电话铃响的动作和事件 ，DCI侧重的是事件 行为，但是事件 行为在客观世界中一般都是由实体发出的；当然在人为的逻辑世界中，比如计算机世界或数学算法世界，行为动作可能没有客体，那么这时就是面向函数编程范式了。
在实际应用中，DDD + DCI 结合起来比较好，这个帖子是我之前针对你疑问结合DDD + DCI 分析图书馆案例：http://www.jdon.com/jivejdon/thread/42751#23136856
这里也有一篇DDD DCI +Events结合的案例：http://www.jdon.com/jdonframework/dci.html
其实DCI 思想，恰好可以作为DDD 中没有被深入的“上下文”的一个另类扩展。
关于banq说实体发出事件 行为，我认为是没有站出领域看领域做成的。我们应该俯视领域，不应该身临领域。整个领域一早就遵循“道”来运转着，与其说“他”主动发出事件 行为，不如说“他”发出事件 行为是必然的——事件。
程序员是创造世界的人，那么用户就是引导（控制）世界的人，但不是参与世界事件 的人。用户不同事件 参与者，用户（事件驱动者）是推第一块骨牌的人，而骨牌是事件 ，参与者只是骨牌内在的逻辑的一部分。所以说我们不应该与领域中的“他”重叠在一起，而是站到领域之外，站在世界之外，去观察这些规律，这些逻辑。
当我看到这一标题，我的直觉是解决问题，但是太粗浅了，更近一步说软件为什么能解决问题，我想是因为软件是现实的反应，软件可以模拟现实的物质和规则，因此特可以解决问题。
物 质有形也是无形，有形如桃子，汽车，无形如工资、温度；这些都是现实的体现。在软件世界中，他们被抽象成对象、数据，他们有喜有乐。缺少它们，软件无法解 决问题，当然它们形态不一，有的身强体壮，能打能抗，能熬夜；有的精通某项个领域；有的擅长调度指挥，有的擅长通讯传递。但是通过他们协作，问题可以被解 决
规则则是贯穿于对象、数据的一言一行中。缺少他们的约束，软件将从有序走向混乱。有些类太强，有些类太弱，有些类太忙，有些类太闲，如果有一天，某些对象倒下了，那软件将何去何从。规则的存在告诉这些居民如何协作，如何让秩序更加有序。
这篇关于关于软件的任务到底是什么的思考的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
