我们目前正在改进我们的架构和应用程序设计。我们刚刚完成了数据访问层的设计，它是通用的，因为它使用 XML 和反射来持久化数据。
现在我们正处于设计业务层的阶段。我们已经阅读了一些与企业架构和设计相关的书籍，因此我们发现很少有模式可以应用于业务层。表模式和域模型是此类模式的示例。我们也发现了领域驱动设计。
早些时候我们决定针对表对象构建实体。但是我们发现在 DDD 中实体和值对象是有区别的。对于那些经历过这种设计的人。请指导我有关模式，实践和样本。
先感谢您！如果您没有得到我的任何观点，也请随时讨论。
@Adil，这不是您最初问题的答案，但我建议您修改您自己的数据访问层的决定。你注意到你想去 NHibernate：现在就去做。
IMO，除非您有一些非常具体的限制，否则编写 ORM 是浪费时间。那里有很多选择，已经投入了数百小时的努力。利用它！LINQ2SQL、实体框架、NHibernate、Subsonic、LLBLGen 都很好，而且还有更多。
还要注意，如果你自己动手，你不会不费吹灰之力就使用 LINQ 的优点。
就分层而言，尽量不要发疯：控制层数并集中精力在它们之间构建一个有价值的接口，以防止您的抽象泄漏。
我见过许多非常“模式化”、层次精美的项目，它们在使用中最终到处都是逻辑，并且持久性抽象到处泄露。把事情简单化！
CSLA.NET作为业务层的基础工作得很好。
@阿迪尔，
无论如何，我不是很有经验的用户，这是我正在使用的模型（也与 NHibernate 一起使用）。
GUI - 包含所有 Web 表单等 BLL - 负责创建新对象实例的目录 DAL - 实现负责与 NHibernate 交互的类的地方。NHibernate 映射文件在这里。
模型 - BLL 和 DAL 使用的类库，用于在对象之间进行数据传输。
使用不同的图案。例如，BLL 和 DAL 具有允许访问接口的 Factory 类。目录是单例类。所有目录都可以使用代表我的业务逻辑顶级对象的主 Singleton 类访问（例如“Enterprise”=>“Enterprise.PeopleCatalog”。
无论如何，希望它有所帮助...
@AngryHacker，谢谢你的提示，你能举一个 CSLA.NET 的例子吗？