bosslee 的做法即是提取出业务规则，正是业务规则引擎的思想，很好.
有个问题，Product自己是否知道它的检查规格？
另一个问题，如果是Component的话，假设有这样的东西存在：
<pre>
书籍类
|---计算机书
|---文学书
|---小说
|---散文
</pre>
现在知道小说类别的不需要检查一定可以下单，而散文类的需要检查，这种如何归类呢？
在这个分类上要依据检查规则类别来分，而这个类别不是产品原生类别，是一个规格类别。那这个Component是否能够适用于这种场景呢？
pre中的类别因空格不显示的问题，看起来不清楚，如有意查看请复制出来看看结构。
[该贴被freebox于2008-06-24 21:29修改过]
您已经都说了是检查规则吗。
如果不要检查的话就不应该能找得到规则吧。
您认为呢？
我觉得这些规格的约束条件所用的量都是归属于OrderItem的量，如果不能归属于OrderItem，另建一个规格对象是有道理的。
我暂时还理解不上去，还需要请各位多多指点。
不要因为逻辑而设计类。我还是感到诸位在往一个死胡同里钻。
现在是因为库存检查的逻辑设计出了类，如果再来一个生产逻辑呢？再有一个运送逻辑呢？
看到if else就要想办法用类绕开，这是笑话。不是所有的if else都是类级别的东西，流程上的每个分支都是一个if else，属于流程的就不要硬往类里塞
另外我很怀疑你这个业务逻辑需求分析是否到位。
就目前来看，某些类别产品是不需要库存检查，但这个是绑死的，内在的类别特性吗？他不会随时间和环境而变化吗？如果不是，这还是个流程上的逻辑。
就我的直觉，这不是类别的一个特性。
如果使用visitor，增加一个逻辑只是在接口中增加一个方法并实现，增加一个类别也容易。
另外一个检查类别是可以被替换的，假设产品“饮水机”原来是不需要检查的，现在因为需要，它变成必须检查的产品，只要替换它的检查类别即可，这个操作是很方便的。
>就我的直觉，这不是类别的一个特性。
accipiter 的分析直觉还是不错的，其实创造性有时就体现在自觉，当然这个自觉是得道后的自觉。
其实accipiter 提出了一个模型分析设计中基本问题：如果它不是类的天然特性；是不是就一定要划入流程？也就是说：是否只有类图和流程两种选择。
个人认为Evans DDD一个特征就是为我们提供了第三种选择，其实也是充血模型的特点所在，这第三种就是Specification。那么Specification和主模型类是什么关系？是一个代理或装饰的关系，而Specification又不属于流程。
前面bosslee引入Specification我比较赞同。
而freebox提出的:
"Product自己是否知道它的检查规格？
另一个问题，如果是Component的话，假设有这样的东西存在"
第一个问题：Product自己是否知道它的检查规格？
因为accipiter的自觉已经告诉我们 "检查规格"不是类别的一个特性，所以，我们目前来看没有必要让Product知道自己的规格，Product和ProductSpecification是一个单向关联，暂时不需要双向。因为是单向，所以，从Product到ProductSpecification可能需要流程的介入，比如下单事件的触发这个流程。
第二个问题：有component存在，如果对设计要求更灵活通用，那么Composite+Visitor，可以参考以前帖子讨论：
http://www.jdon.com/jivejdon/thread/23857.html
[该贴被banq于2008-06-25 19:34修改过]
又抽时间读了一次第9章，是否可以这样理解：
因为“是否检查”是一个Product相关的领域动作，但却不是Product的特性，仅在“检查发生”时，这个约束才有用。并且它的结果是谓词，所以把它看作规格。
一开始就考虑设计模式..
只会把问题搞复杂..
个人认为就从最简单开始..
在这个模型中用个"策略"最直接..
一开始肯定是简单好，不要陷入过度设计的泥沼，在需求变化的同时不断地重构，过程迭代!
willem
-->>但是按照楼主的描述，是否需要库存检查是和具体的类别有关的，就是说一旦产品的类别被确定了，无论是否下单，它都能够确认是否需要库存检查。
是的, 检查库存不只是在下单时才用上,可能在其它的地方要用.
accipiter
如果是这种内在的逻辑，那是应该绑定在所在的类上面。有一个前提条件，类的粒度应该与方法相同。换句话说，该方法不应依赖于实例而存在。
就当我前面什么没说过吧。
>如果是这种内在的逻辑，那是应该绑定在所在的类上面。
本人观点：觉得这句话有道理哦。看上去好像就是某一产品类型的一个特性（需不需要库存检查）
willem
->
现有一个库存检查的逻辑:
对A类别的产品: 不需要库存检查,可下单,
对B类别的产品: 一定要库存检查,有库存可下单,无库存不能下单
对C类别的产品:
购买该类别的客户需要选择送货周期,如果
客户要求的送货周期大于30天,是不需要检查库存(即30天后一定可以送货),如果小于30天需
要检查库存.
本人看法：
“对B类别的产品: 一定要库存检查,有库存可下单,无库存不能下单”从这句描述看，涉及三个逻辑：要不要库存检查，可不可下单，有无库存。本人觉得要不要库存检查是由某一产品类别决定（也就一个布尔型属性），可不可下单是订单根据此类产品是否有库存来决定，责职好像挺明确的。
willem的需求是否可以如下描述：
A类别的产品直接可以下单（也就是一定有库存）
B类别的产品有库存可下单,无库存不能下单(那自然就要进行库存检查啦)
C类别的产品送货周期大于30天直接下单，小于30天要有库存方可下单
不知willem的核心需求是不是要确定能否下单？其实有点困惑你本意是想确定能否下单，还是要确定是否要进否库存检查，好像要不要存库检查没什么意义。我认为不需库存检查就是可下单的一个直接条件，说白了就是一定有库存，可以下单；要库存检查就是还没确定是否有库存，因此先要检查库存才可作出能否下订单。
概括起来就是有库存可下单，否则不可下单。不需库存检查归属有库存这一条件。每种类别定义是否有库存的检查规则。比如A类型，是永恒有库存。
个人看法，不妥之处，请指教批评。
[该贴被sonnylys于2008-08-02 19:33修改过]
感觉前面的讨论似乎一开始就偏重设计了，有点为设计而设计。而没有把需求真正分析清楚，前面的总结才是根本。
>概括起来就是有库存可下单，否则不可下单。不需库存检查归属有库存这一条件。每种类别定义是否有库存的检>查规则。比如A类型，是永恒有库存
为什么要这样加入自己判断来对需求进行“扭曲”呢？
需要通过你的变通，可以节省判断“是否需要库存检查”这个环节，直接跳入库存检查，也就是说：无论什么类别都进行库存检查。
可是需求就是需求，是不能变通，况且从性能和效率等其他角度考虑，如果业务上能够确定一类产品无需检查库存，不是节省这类产品的下单效率吗？
所以，需求没有必要去变通，老老实实按照需求去做。软件人的聪明应该体现在分析和设计上，而不是和客户讨价还价。