这是一个主观问题，但通常为了强制模型对象不直接依赖基础设施，人们经常将它们放在一个单独的项目中。您还需要考虑其他项目可能使用这些模型对象。

将功能分离成单独可部署单元（程序集）的另一种选择是为了让团队更加独立地运作。根据部署频率和团队自主性分离项目。

最后，我看到过一些项目，在这些项目中，模型对象是通过远程调用（例如使用.NET远程调用）并在应用程序服务器上提供，而不是在Web服务器上提供。我真的不推荐这种方法，但这也是一个选择。

如果您不计划重复使用它们，并且您意识到将它们放入同一组件允许您创建与该项目中定义的任何其他内容的交叉依赖关系，但您足够聪明不这样做，您可以将所有它们放入同一项目中。

话虽如此，99%的时间我都有这些项目：

• UI
• Core
• Persistence
• Tests

但是你仍然需要考虑你的项目需求。

a sweet tooth, and I love eating desserts. 我倾向于爱吃甜食，特别是甜点。

• Justice.Project.Core — the POCO domain model — i.e., business objects)
• Justice.Project.Data — NHibernate mappings etc., where the persistence scheme resides
• Justice.Project.Services — repositories, as well as business logic which cannot easily be fit into the business objects
• Justice.Project.(Web|UI)

该模型应该是业务对象。

我的解决方案包括3个项目（非测试项目）

1. UI - obvious
2. Core - all domain objects and business logic
3. Data Access - Repository pattern for populating/saving Model objects

i agree that the model objects go into POCO. so lets say i have an Order object. My question is where do i have the class that stores a collection of orders ??

那取决于你的业务。最可能的是你会有一些订单分散在几个不同的地方...

在您的客户对象上，每个客户应该有一个订单集合，因此您需要在那里创建一个。

如果你有部门，每个部门应该有他们创造的订单集合。

如果你有仓库，每个仓库可能会有一系列订单，他们负责履行。

一些对象没有父级，这很好。在我的系统中，我们有客户端。客户端的真实世界所有人是我们（企业），但系统中没有“我们”对象。如果您要获取客户端列表（在我们的情况下），我们会查询存储库获取它。

IRespoistory<Client> repository = new Repository<Client>();
IList<Client> clients = repository.GetAllClients();

同样的情况也可以适用于你的订单。

我建议查看这本DDD书籍：http://www.amazon.com/gp/product/0321268202/ref=s9k2a_c1_at1-rfc_p-3237_p?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-1&pf_rd_r=1BWAPTN787CTZXJDV5BA&pf_rd_t=101&pf_rd_p=463383351&pf_rd_i=507846