对于域驱动的设计RESTful Web服务，这是否是一个好的Visual Studio解决方案结构？

15

我正在构建.NET 4.5 C＃Web API RESTful解决方案，我想告诉我我的项目解决方案对于使用域驱动设计设计的解决方案是否正确和/或明智（足够？）。

该解决方案已分为6个项目：

/基础

（没有任何引用）

该Web项目构成了解决方案与外界之间的接口。包含Web API控制器。除了从请求对象中收集值并要求BizApi层工作以外，几乎没有任何逻辑。

/Biz.Api

（由基础引用）

提供域服务，并允许/ Base接口项目访问/Biz.Domain项目中的域业务逻辑对象。

/Biz.Domain

（由Biz.Api引用）

提供Biz.Api层的域类。这些提供了操作内存中业务数据的方法。

/Dal.Db

（由Biz.Api引用）

数据库存储库层。访问数据库并将返回的数据映射到/ Interfaces层中定义的内部DTO。

/Dal.Services

（由Biz.Api引用）

为外部依赖项（如Web服务）提供代理层，并将其返回的数据映射到/ Interfaces项目中定义的内部DTO。

/接口

（以上大多数项目引用）

包含用于在解决方案中传递数据的DTO类和用于为IoC之类的合同定义合同的C＃接口。

c# rest domain-driven-design

— 马特·W
source

“ /Biz.Api提供域服务”：您是指应用程序服务吗？同样，存储库通常不返回DTO，而是返回实体（聚合根）。而且这些项目之间的依赖关系也很容易知道；）

— guillaume31 2014年

是的，我的意思是应用服务。存储库返回的类实例除了存储数据外什么也不做-在这种情况下，此数据使用AutoMapper映射到实例中。返回的实例没有操纵方法，我收集的实体确实具有。

— 马特W

“此数据被映射”：在什么和什么之间？您所说的“操纵方法”是什么意思？

— guillaume14年

22

这种文件夹结构的灵感来自沃恩·弗农（Vaugh Vernon）着名的《实现域驱动的设计》一书。

解决方案：
├的WebService ^{_{（REST服务在这里驻留）}}
├WebServiceTests
├应用^{_{（应用服务居住在这里）}}
├ApplicationTests
├域名^{_{（实体，VO，域名服务，域名工厂，规格，域事件，库界面，基础架构服务接口）}}
├DomainTests
├基础设施^{_{（存储库，基础设施服务隐含，外部服务的适配器）}}
└基础设施测试

我从解决方案开始，然后为应用程序中的每个层创建四个项目，然后为每个层测试创建另外四个项目。

不要在文件夹interfaces或services域层中创建文件夹，而应根据模块中的功能对相关类进行分组。

— 松乡
source

1

就结构而言，对我来说似乎还可以，尽管我会想出不同的，更具描述性的名称，例如"YourProjectWebApi"代替"Base"，"Dal.External"代替"Dal.Services"等等。

不过，“内部DTO”部分可能会有气味，因为您应该将实体从存储库中取出，并能够直接对存储库执行域（业务）操作。实体不只是DTO的。

我Dal.Db从不依赖于Biz.Domain,域层在Interfaces项目（由Repositories返回）的DTO与它自己的Domain对象之间进行某些映射这一事实中收集了一点。在典型的最新技术（==“洋葱”或“六角形”）DDD体系结构中，这是不正确的-域层不应引用其他项目。出于相同的原因，存储库接口应该在域中声明，而不是在Interfaces我想的地方声明。

— guillaume31
source