例如，
EmployeeID：123
员工姓名：John Doe
州：阿拉斯加州(下拉)
县：Wasilla(下拉 – 将根据状态过滤)。
例如，假设您有一个Employee域对象，一个IEmployeeRepository接口和一个EmployeeRepository类。这将由UI用于显示员工和个人详细信息的列表。在UI中，您希望使用员工居住的州和县的下拉菜单。可用县将根据选择的状态进行过滤。
不幸的是，数据库表和UI看起来非常不同。在tblEmployees中，它包含州代码= AK和县代码= 02130，而不是州和县名。
旧的方式(在我开始这个DDD任务之前)将是非常简单的，只需创建2个查询，并使用DataReader填充下拉列表。下拉列表中的显示下面是值，它会自动在表单发布中使用。
有了DDD，我不知道你应该怎么做。我首先创建状态和县对象以及存储库的存储库和接口。然而，在hbm.xml文件中编写4个类2接口和管道员工业务对象看起来像2个下拉列表的2个查询的过度。有一个更好的方法，不是吗？我不会改变州或县表中的记录，即使我做了，也不会通过这个应用程序。所以我真的不想创建业务对象的州和县，如果我不必。
我看到的最简单的解决方案是使用返回字典的方法创建一个辅助类，例如GetStatesAll()，GetState()和GetCounties()和GetCounty()，但是从DDD角度来看只是感觉错误。
请帮忙。如何使用DDD而不需要进行简单的查找？
最终解决方案
我认为我终于通过经验找到我的答案，这是把GetStates()方法到自己的数据访问类，虽然不是一个存储库类。因为我只做只读访问，我把它转换成一个结构DTO。由于数据库很小，我把它们全部放到一个类中，像下面描述的Todd。
我的结论：
>查找表是NEVER值对象，因为查找表始终具有标识。如果他们没有身份，你会有重复，这不会有什么意义。
>只读查找表可以有一个存储库，但可能不需要一个。存储库的目标是通过强制仅通过聚合访问来降低复杂性。通过聚合提供了一种确保可以实施业务规则的方法，例如，如果您没有汽车，则不添加轮胎。
>如果允许在查找表上进行CRUD维护，则查找表具有其自己的存储库是有意义的。
>事实上，我最终将代码存储为结构体不会使它们成为“值类型”。 Fowler在POEAA中说，struct是一个值类型。这是真的，结构是不可变的，这就是为什么福勒说，他们是“价值类型”，但我使用他们不同。我使用结构作为一种轻量级的方式传递DTO，我没有计划在初始创建后更改。事实上，我使用的结构确实具有身份，但是因为它们是只读的，所以它们作为结构体。
>我一直在使用的一个模式，我在其他地方看不到的是使主键字段不可变。它们由构造函数设置，但是它们是只读的(而不是私有访问器)，并且一旦对象被创建就不能被改变。
你可能想花一些时间阅读Greg Young的博客从this one开始到现在。他不专门讨论填充查找数据，但他经常谈论不通过在存储库上的类型化方法处理应用程序的读取/报告功能。
