我正在为应用程序设计解决方案结构。我打算使用领域驱动设计。Asp.net MVC 和实体框架。在某些领域需要您的投入。
数据访问首先使用实体框架代码设计存储库构建在 EF 数据访问之上 域模型是在存储库之上使用域模型设计的 应用程序服务构建在 Damain 层之上 UI 开发在应用程序服务之上
流量是
UI（控制器）--> 应用服务--> 域层--> 存储库--> 数据访问--> 数据库。
我不太清楚如何在层之间共享数据。
My Domain 模型可用于在存储库、数据访问和域层之间存储数据。我只是在想数据应该从 Daomin Layert 传递到应用程序服务和应用程序服务到 UI 的方式。我可以使用 DTO，但不确定它是否是一个好的选择，因为我有一些模型已经在域模型中，在 UI 中查看模型。
给定您描述的流程，在 UI 层中创建视图模型以由控制器实例化。视图模型是视图绑定到的简单对象。这应该与底层域模型分离，以解决namkha87指出的问题。
至于数据访问层，您可以使用域对象本身进行对象关系映射，因为 EF 允许这样做。这里不需要中间 DTO。
要考虑的另一件事是将用于查询的模型与用于调用行为的模型分开。这样，您可以确保应用程序服务永远不会公开行为域对象，只会公开read-models。让应用程序服务将域对象暴露给外层的问题在于，它将允许那些外层调用这些对象上的行为，结果是未定义的。当您只返回没有行为的只读对象时，这不是问题。对于返回的数据，不要让 UI 层直接创建域对象 -您应该区分实体和简单数据。
重用 Domain Model 或 UI Model 不好，它会让你的层紧密耦合。以这种方式开发大规模应用程序非常困难。
你认为是正确的，Application 是一个薄层，它只是一堆 Actions，会直接从 UI 层调用，信息将通过一个名为 ActionParameter 的对象传递。ActionParameters 定义在Application 层，ActionParameter 对象构建在UI 层并传递给Application 层。
应用程序将通过数据访问层从数据库中检索数据。查询操作有时需要从许多源、不同的域实体中获取数据，并且需要在返回 UI 层之前对数据进行投影、转换或格式化。我们将有类似 ActionResult 的对象，其中包含要返回给 UI 层的所有数据。
似乎会有很多代码，但我认为这是必要的。每一层都有自己的用途，当我们改变一层时，其他层不会受到影响。