我想讨论讨论，系统功能，接口，实现类之间的一些关系。
假设一个系统：
已经知道了系统的功能需求，我怎么根据我这些功能建立好设计模型呢？
有些什么一般性的准则么？
也就是说，我怎么知道该定义些什么样的接口，什么样的类实现。
我看模式书上，接口定义的时候好像都是“动词”，而实现类定义的一般都是名词，也就是说是这个动词的主语。
比方说，人喝水，狗喝水，兔子喝水，这样一个语义功能，就会这样描绘：接口是 IeatFood ,而实现类就是people，dog,rabbit。
那么我们可不可以这样理解呢，接口就是功能（动作，能力）？而执行这个功能的主体就是实现类了，这样我们是不是就把系统从现实世界中转化到了计算机设计模型上了呢？这个算是一条捷径吧！
大家讨论讨论呀！
功能用例需求中寻找 Domain Object（Entity Object），我称之为基本业务对象，使用接口表现出来。
这个讨论有点意思，楼主的思路是对的，Bang说的Domain object(Entity object)不是持久层的意思吧，而是问题/业务领域的本质功能接口吧？
是的，Domain object(Entity object)不是持久层，持久层概念只有在设计实现时才会使用到。
所以我称为基本业务对象，是属于业务领域的本质，如何从系统功能中寻找出正确的本质的基本业务对象，是一个项目成功的开始，也是项目架构的出发点。
如果基本业务对象提炼错误，或偏差，系统的方向相当于走偏了，开发成型后，是无法通过fix bug来解决的。
这里也体现了一个系统的必须要有一个具有丰富经验的设计师或架构师来把握，不能再象过程语言系统那样，由程序员自己想到哪里，开发到哪里。
缺乏这种架构师的公司可以通过聘请咨询公司来解决，J道包括我就提供这样的收费服务，可惜，目前很多公司包括有经验的程序员都没有认识这一点，这样的人员组成的IT行业能不萧条吗？
斑竹说的非常准确，那么这个基本业务对象是如何提炼呢？斑竹能介绍一些方法和原则么？比方说，看那些方面的书籍，考虑哪些问题？
我的理解是，中国人都讲究五行相克，作为一个软件领域的东西，答案可能我们不能再从软件行业里面来寻找了，软件工程那一套东西，我想是不能再行通了，我们应该学习的是很多现实世界的东西，比方说，一个软件，可能对于不同地域的用户，对于不同思维习惯的人来说，大家的理解都是不同的，这样我们就有必要先学习各种文化，思维习惯了，但是这样学下去，路漫漫了。。。。
请斑竹介绍介绍经验之谈？
>对于不同思维习惯的人来说，大家的理解都是不同的
但是总有些人的理解会更接近系统的本质，任何系统都有规律，如何总结取决于设计人员的经验的素质。
阅读源码是一种经验培养的办法，参考源码系统是如何提炼基本业务对象的，有什么缺点，有何优点，从多个源码学习实践中可以培养出这种提炼的经验。
阅读几套源码，相当于读万卷书，注意，一定要多个类型的源码，否则，只是钻研在Jive或petstore这样单个系统中，思路和思维反而被其所引导，需要通过自己实践，将思维提升到一个新的高度。
请问“多个类型的源码”是指哪些类型，或者说划分类型的标准是什么？
struts/petsore/jive/ofBizs/in apache......
他多了，如何选择？？？
偶提炼的结果是
任何业务的任何操作都是一组数据（操作对象）对另外一组数据（被操作对象）进行的操作～，最后生成一组数据
我觉得，软件开发，特别是一些business的，都是映射现实世界的，将原来需要人来做的事情自动化，因此好的软件开发者，必然对软件要解决的领域问题非常清楚，首先是一个领域专家，计算机只是一个工具
我想从OO的角度可以如下开始：
1。既然知道了明确的需求，那么应该可以或者已经构建了你的用例模型。简单一点，类似于系统的功能分解，这一步不用考虑如何做，权且尽力考虑做什么。
2。在此用例的基础上可以构建系统的结构，所谓结构既定义了实现该系统所必需的关键组件和这些组件之间的契约关系。同时经过分析人员的脑力劳动，我常常是假象各部分的功能，做到在头脑里依次结构假象的系统可以完整地运行。（所谓概念模型）
3。有了系统的构架，那么对于每个组件的借口还是模糊的。接下来就是详细分解各部分功能，可以从最核心组件的开始，一步一步向外拓展。同时我的做法是可以开始完成核心组建就开始实现之，一来检验这个构架现实可行性，二来给你接下来的工作提供信心:)
到这里应该是基本差不多，个人习惯，全当抛砖。
photonman确实有这方面经验，非常正确。
“核心组件”的思想和我很相似，我总是用代码实现一下这个核心核心组件，DEMO通过后，才对这个架构有信心，可以继续深入拓展和设计。
接口一般用来定义一类事物共有的行为，特性。
声明为动词，形容词，名词都可以。
在设计时如何定义接口，具体类在刚开始设计时确实很困难。
一种就是依靠行业知识，也就是domain object来确定哪些需要抽象。
还有就是要有一些design principals的知识，比如SRP, DIP, ISP，类和类直接，层和层之间，尽量只依赖于抽象。
在实现中持续做refactory，一旦发现可以提供抽象的，就做extract interface。
有的时候是用抽象类来实现类的规则。接口和抽象类方法有时很相近。在设计时又如何来区分那？
抽象类继承又称为write box implement，接口继承又称为black box implemnt。
对于抽象类继承，一般要知道父类的实现逻辑。
接口继承则没有限制，有更大的自由。
所以对于最终用户，尽量只提供接口调用。
我有一些不同的想法：
banq说，分析应从实体对象开始。而我的习惯是从业务逻辑开始，也就是说从行为开始。也许我对banq的说法理解有误。