이것이 도메인 중심 디자인 RESTful 웹 서비스에 적합한 Visual Studio 솔루션 구조입니까?

.NET 4.5 C # Web API RESTful 솔루션을 구축 중이며 도메인 기반 설계를 사용하여 설계된 솔루션에 대해 내 프로젝트 솔루션이 정확하고 현명한 지 (아마도) 알려달라고 부탁합니다.

이 솔루션은 6 개의 프로젝트로 분할되었습니다.

• /베이스

(아무것도 언급하지 않음)

웹 프로젝트는 솔루션과 외부 세계 사이의 인터페이스를 형성합니다. 웹 API 컨트롤러를 포함합니다. 요청 오브젝트에서 값을 수집하고 BizApi 계층에 작업을 요청하는 것 이상의 논리가 거의 없습니다.

• /Biz.Api

(기준으로 참조)

도메인 서비스를 제공하고 / Base 인터페이스 프로젝트가 /Biz.Domain 프로젝트의 도메인 비즈니스 논리 개체에 액세스 할 수 있도록합니다.

• /Biz.Domain

(Biz.Api 참조)

Biz.Api 계층에 대한 도메인 클래스를 제공합니다. 이들은 메모리에서 비즈니스 데이터를 조작하는 방법을 제공합니다.

• /Dal.Db

(Biz.Api 참조)

데이터베이스 저장소 계층. 데이터베이스에 액세스하고 반환 된 데이터를 / Interfaces 레이어에 정의 된 내부 DTO에 매핑합니다.

• /Dal.Services

(Biz.Api 참조)

웹 서비스와 같은 외부 종속성에 프록시 계층을 제공하고 반환 된 데이터를 / Interfaces 프로젝트에 정의 된 내부 DTO에 매핑합니다.

• / 인터페이스

(위의 대부분의 프로젝트에서 참조)

솔루션 주위에 데이터를 전달하기위한 DTO 클래스와 IoC와 같은 계약을 정의하기위한 C # 인터페이스가 포함되어 있습니다.

이 폴더 구조는 Vaugh Vernon 의 유명한 구현 도메인 기반 디자인 북 에서 영감을 받았습니다 .

솔루션 :
├ WebService ^{_{(REST 서비스가 상주)}}
├ WebServiceTests
├ 응용 프로그램 ^{_{(애플리케이션 서비스가 여기에 상주)}}
├ ApplicationTests
├ 도메인 ^{_{(엔티티, VO, 도메인 서비스, 도메인 팩토리, 사양, 도메인 이벤트, 리포지토리 인터페이스, 인프라 서비스 인터페이스)}}
├ DomainTests
├ 인프라 ^{_{(리포지토리, 인프라 서비스, 외부 서비스에 대한 어댑터)}}
└ 인프라 테스트

솔루션으로 시작한 다음 응용 프로그램의 각 계층에 대해 네 개의 프로젝트를 만든 다음 각 계층 테스트에 대해 다른 네 개의 프로젝트를 만듭니다.

폴더 interfaces나 services도메인 계층을 만들지 말고 관련 클래스를 모듈의 기능별로 그룹화해야합니다.

구조에 관해서 "YourProjectWebApi"는 "Base", "Dal.External"대신에 "Dal.Services"나 대신에 와 같이 다른 자기 설명 적 이름을 생각해 냈지만 괜찮습니다 .

"내부 DTO"부분에 냄새가있을 수 있습니다. 엔티티를 저장소에서 가져오고 도메인 (비즈니스) 조치를 직접 수행 할 수 있기 때문입니다. 엔티티는 단지 DTO가 아닙니다.

Domain 레이어가 Interfaces 프로젝트 (Repositories?에서 반환)의 DTO와 자체 Domain 객체 사이에 매핑 을하고 있다는 사실에 Dal.Db의존하지 않습니다 Biz.Domain,. 이것은 일반적인 최신 기술 (== "양파"또는 "육각형") DDD 아키텍처에서는 정확하지 않습니다. 도메인 계층은 다른 프로젝트를 참조해서는 안됩니다. 같은 이유로 리포지토리 인터페이스는 도메인에서 선언해야합니다 Interfaces.