今天在看houghtWork公司写的《Pragmatic.Bookshelf.The.ThoughtWorks.Anthology》书的时候，发现，Erik也在讨论Domain与infrastructure，不过里面只是简单的提了下，如下：
Erik considers a similar problem. In a well-designed system,
you decouple the domain model from infrastructure layers, but this
requires that the infrastructure layer use the metadata present in the
domain model. Some implicit metadata can be gleaned from what’s in
there such as the choice of classes to represent certain domain elements,
but it doesn’t really provide enough information for really rich
stuff like validations. Some modern languages such as Java and C#
provide for more metadata in the form annotations and attributes, and
Erik explores how to exploit these features through a case study.

业务还是交给domain来处理，不要构造where逻辑。
比如现在图书要打折，规定按类别和进货时间区分打折率：
1、只有“电子工程类”和“营销管理类”打折
2、以上两类打75折，但如果原书价格高于（包括）50元，折后价格不得低于（包括）50元，低于50元的按50元计。（如果此书恰巧50元，真不幸，它等于没折）
这种“打折率”问题是经常变化的，他们不可能指望每更改一次规则就要人弄个新的类部署。在第一次需要变化的时候我们找到了解决“哪类图书打折”的方案，并意识到“打几折，如何折”也是个变化，我们把这个规则所要的数据写在XML里，并提供了一个页面来供录入，每当新的数据录入后，打折规则会被重新载入并备份之前的规则（这是他们另一个需求，要求可以随时看到因促销对图书价格曾做过些什么）。
那这个东西交给DAO还是domain来处理？可以构造一个where和表达式运算来查询，也可以直接找出来，之后交给domain运算（反正也是要这些书，只不过价格跟db里的有出入需要domain按规则修正一下）