面向使用的软件设计

现在软件技术发展的边际效应呈现出逐渐减少的趋势，这个 Domain Object 说的再神奇，也没有我学习《设计模式》的时候感觉的收获那么大。TDM 认为技术发展到今天，真正提高开发效率的并不是技术本身，而是需要更加关注人的因素，创造更好的环境，激发出人的积极性和创造力。每一个 PM 带项目或者做产品，你不可能一个人做完所有的事情，必然要把大量的工作分配给手下的程序员来做。你吃过了六个馒头，但是这些程序员可能只吃到了第二个馒头，还有些夹生。那么你有没有考虑过如何简化系统的架构，让他们更加容易理解，能够顺利地跟上来不至于掉队？只有这样，才能有效地降低沟通的成本，并且改善产品的质量（对于复杂的架构不理解是产生 bug 的根源）。还有你有没有真正在关注用户的需求，用户真正关心的是什么你知道吗？还是仅仅拘泥于 Domain Object 的范式上面？ 假如这个优美的 Domain Object 并不能为更好地实现用户的需求而服务，并且还为系统增加了不必要的复杂性，那么这个 Domain Object 是不是一种屠龙之技呢？软件的本质其实是一种服务，我可以负责任地说，我们所有参与讨论的人其实都不是真正的研究人员，我们并不是在做技术，而是在做服务。这个就是以前我说的“用户永远不需要技术”的含义。用户需要的是什么？其实是一种高级的服务。理发师的敬业精神体现在为用户理好发，那么我们的敬业精神就是体现在为用户做好服务上面。其实除了产品规划和设计的早期工作比较有创造性（我们并不会在设计上花费非常多的时间，因为我们并不相信存在着完美的设计）以外，我一天的大部分工作时间都是在解决一些琐碎的问题上面。我可并不害怕做小事情。我并不相信一个简单的 Domain Object 就可以做出一个优秀的产品来，创造出一个优秀的产品需要各方面技能和经验的积累，需要每一个参与者的通力配合。

我最近在看《面向使用的软件设计》，感觉很有帮助，推荐大家也看一看。

关于这个帖子的编程模型，我用的是一个简化的模型。
Partech的帖子给出的是一个详细系统的解决方案。思路清晰明了。我觉得很好。Partech也非常注意package之间的依赖关系，并给出了解决方案。



Partech很娴熟地用接口解决了 层次相互依赖 这个问题，虽然有些颠覆传统的层次依赖习惯。

我也主要是针对这里，提出了这个帖子。
为了使用Domain Object, 而付出 “依赖关系倒过来”的代价。收获大于付出吗？
由此而想到，多态的需求下，Domain Object的编程结构是美好、方便的。
但在实际的应用中，多态的需求不一定有那么多。
所以，我就多唠叨了几句，“根据情况，权衡利害。不必拘泥于范式、定则。”:-)

to buaawhl：
我其实从大家的讨论中也学到了不少东西。不过这类讨论非常容易没有结果，容易陷入路线和主义之争。我发这个帖子说的没有一句话和技术沾边，可以说对 Domain Object 是完全的外行。我只是希望和以前庄表伟一样首先确立一个衡量技术优劣的标准。离开了具体的业务，就容易陷入空谈，而具体的业务要谈清楚也不是那么容易的，甚至有的时候还无法在公开场合谈论，这些限制使得这类讨论变得很单薄，不够丰满，其实 Domain Object 也不过只是一个骨架而已，还需要填充上业务问题的血肉才行。

比如和某人讨论 EJB 的缺陷，某人首先否定根本就没有轻量级和重量级的区别，然后将所有反对其意见的人都抹黑为卑鄙小人，犯了红眼病故意来断人的财路。似乎这些问题永远都没有讨论清楚的一天，至少大部分旁观者都是这样看的。但是我并不这样看，我依然认为这些问题还是需要讨论，不讨论就更加不清楚，更容易被某些人浑水摸鱼了。

真应该把自己项目中遇到的实际问题切出来，然后大家把枪对着问题狂扫！！

是啊。离开了具体的业务标的物，大家都从自己最熟悉的观点和立场来理解，而难以相互交谈清楚。
路线、主义之争论，我也觉得，应该尽量避免。
Partech的帖子开头也是这样的观点。


比较喜欢这种气氛和开场白。:-)
我想，在讨论的过程中，这种气氛也会逐渐浓郁起来的。

前段时间在北京实施一个项目，切身体会到的一些东西，让我觉得技术真的不重要（注：相对而言的），如dlee所说，服务才是根本，如何做好服务，如何带领人做好服务，如何培养出能做好服务的开发人员，现在是我准备研究的内容，当然，我还是会从技术入手，但是更趋向如何把技术合理利用，带动开发团队。ddd我认为将来肯定会热，不过，对于目前实际开发来说，也肯定是远水，它需要一整套的开发过程和成熟团队支持才能被应用到具体项目中，毕竟大多数的公司不是研究院。

Domain Object不是银弹，是一种方法论。将面向对象的一些概念应用到业务分析的领域。

在设计和开发、测试领域都已经有不少成熟的方法论了，但是我觉得在业务分析领域的成熟方法论还太少，因此我觉得进行讨论是很有必要的。

至于说到服务和技术哪个重要，估计很难有定论的，尤其是“服务”的概念实在太宽泛了……

要是需要那么多条件才能用用的话, 那东西只怕就没什么用处.
研究院才不会关心什么ddd, 只有做实际工作的人,才需要这类东西.

一个前提：技术的必要性问题。
如果解决一个问题必须上6个馒头的技术，那么只能将吃2个馒头的人开掉。
如果2个馒头就能解决问题，有选择余地了，我想技术的必要性就体现在非功能性的那些东东上了，比如可扩展性，复用性，架构清晰等。2个馒头可能还是不行，但已经有行的可能了(因为可以不选择那些非功能性的东东)。
我觉得到具体问题如何处理上可能要集中到这些可能可以称为软指标的东东上来。
就人下菜？还是就菜下人呢？根据员工定这些软指标还是根据软指标要求员工呢？

对DLEE的话，深表赞同。

虽然都是做开发，都是做企业应用，不过，不同的行业，不同规模的客户，实际所要求和所测重的，都是有着很大的区别的。

越是信息化程度越高越成熟的行业，越是规模越大的客户，国内最典型的可能就是银行了，就越接近DLEE所说的“软件的本质其实是一种服务”的这个概念。

他们不会再将重点关注于何种技术，而是更关注于是否能提高实际的业务能力和效率，以及出现在实际问题中的种种问题。


又一句经典，我们常常会抛开实际的业务，而泛泛的空谈各种技术的优劣好坏，甚至陷入口水战。

举个不恰当的例子，一些经验丰富的老程序员，可能已经有近十年的某一行业的开发经验，也许他不懂DDD，也许他也不会象现在这样纯理论的抽象，甚至于他对面向对象也没有到达我们所谓的完全的分析和设计的境地。他只是用EJB，只是用面向事务的编程，同样可以做到非常优秀的行业产品，同样的易于维护易于扩展，这并不是因为他的分析和设计理论有多好，而是因为他有着丰富的行业经验，能够把握住行业中业务的本质，能够预料到应有的变化。

这并不是假设，现实中，的确有这样的老程序员们，他们才是最最稀有，最最珍贵的。