我们正在修改我们的架构和应用程序设计。我们刚刚完成了数据访问层的设计，这是通用的，它使用XML和反射来保存数据。业务层设计
现在我们处于业务层设计阶段的任何方式。我们已经阅读了一些与企业架构和设计相关的书籍，因此我们发现可以在业务层上应用的模式很少。表格模式和领域模型就是这种模式的例子。我们也发现了领域驱动设计。
此前我们决定针对表对象构建实体。但是我们发现，在DDD方面，实体和价值对象存在差异。对于那些经历过这种设计的人。请引导我相关的模式，实践和样本。
预先感谢您！如果您没有得到任何意见，请随时与我们商量。
CSLA.NET很适合作为业务层的基础。
@Adil，
我不是很experient用户，无论如何，这是模型的那种我使用（也与NHibernate）。
GUI - 所有的网页表单等 BLL - 这是负责创建新对象 DAL的情况下的目录 - 在负责交互类与NHibernate实现的地方。 NHibernate映射文件在这里。
模型 - 由BLL和DAL用于数据传输对象之间的类库。
使用不同的图案。例如，BLL和DAL有一个允许访问接口的Factory类。目录是Singleton类。所有目录的使用访问代表我的业务逻辑主Singleton类顶级对象（例如，“企业” =>“Enterprise.PeopleCatalog”。
不管怎么说，希望这有助于...
@AngryHacker，感谢您的提示，你可以给一个CSLA.NET的例子吗？
@Adil，这不是你原来的问题的答案，但我建议你修改你的决定，推出自己的数据访问层。注意，你想去NHibernate：现在就做吧
国际海事组织，写一个ORM是浪费时间，除非你有一些非常具体的限制。这里有很多选择，已经有数百小时的努力。利用它！ LINQ2SQL，Entity框架，NHibernate，Subsonic，LLBLGen都很好，还有更多。
请注意，如果你自己推出，你将无法使用LINQ的优点，而无需付出很多努力。
就分层而言，尽量不要发疯：保持图层的数量，集中精力建立一个有价值的界面，以防止抽象泄漏。
我见过很多非常“有图案”的，精美的分层项目，最终使用的逻辑随处可见，并且持久性抽象泄漏到各处。把事情简单化！
另外，我们可能需要将来使用NHibernate！ – 2010-05-25 05:59:04