使用DDD的应用程序设计

Question

我正在为应用程序设计解决方案结构。我打算使用域驱动设计。 Asp.net MVC和Entity框架。在某些方面需要你的输入。

数据访问首先使用实体​​框架代码设计 Reposirotires建立在EF Data Acces之上 域模型是在存储库之上设计的域模型 应用程序服务构建在Damain层之上 UI是在应用程序服务

之上开发的

流程是

UI（控制器） - ＆gt;申请服务 - ＆gt;域层 - ＆gt;存储库 - ＆gt;数据访问 - ＆gt;数据库。

我不太清楚如何在各层之间共享数据。

My Domain模型可用于在存储库，数据访问和域层之间生成数据。我只想到数据应该从Daomin Layert传递到Application Service和Application Service到UI的方式。我可以使用DTO，但不确定天气是不是一个好选择，因为我有一些模型已经在域模型，UI中的视图模型。

Answer 1

重用域模型或UI模型并不好，它会使您的图层紧密耦合。以这种方式开发大规模应用程序非常困难。

你认为是正确的，应用程序是一个薄层，它只是一堆将直接从UI层调用的动作，信息将通过一个名为ActionParameter的对象传递。 ActionParameters在Application层中定义，ActionParameter对象在UI层上构建并传递给Application层。

应用程序将通过数据访问层从数据库中检索数据。查询操作有时需要从许多源获取数据，不同的域实体和数据需要在返回到UI层之前进行投影，转换或格式化。我们将使用ActionResult对象，其中包含要返回到UI层的所有数据。

似乎会有很多代码，但我认为这是必要的。每个层都有自己的用途，当我们更改一个层时，其他层不会受到影响。

Answer 2

根据您描述的流程，在UI层中创建要由控制器实例化的视图模型。视图模型是视图绑定的简单对象。这应该与基础域模型分离，以解决 namkha87 所指出的问题。

就数据访问层而言，您可以将域对象本身用于对象关系映射，因为EF允许这样做。这里不需要中间DTO。

要考虑的另一件事是将用于查询的模型与用于调用行为的模型分开。这样，您可以确保应用程序服务永远不会公开行为域对象，仅read-models。让应用程序服务将域对象暴露给外层的问题在于它允许那些外层调用那些对象上的行为，结果是未定义的。当您只返回没有行为的只读对象时，这不是问题。对于返回的数据，不要直接在UI层创建域对象 - you should distinguish between entities and simple data。