14

I am building a .NET 4.5 C# Web API RESTful solution and I would like someone to tell me if my project solution is correct and/or wise(-enough?) for a solution designed using Domain Driven Design, please.

The solution has been split into 6 projects:

  • /Base

(Not referenced by anything)

The web project and forms the interface between the solution and the outside world. Contains the Web API controllers. Contains almost no logic beyond gathering values from request objects and asking the BizApi layer for work.

  • /Biz.Api

(Referenced by Base])

Provides the domain services and allows the /Base interface project to have access to the domain business logic objects in the /Biz.Domain project.

  • /Biz.Domain

(Referenced by Biz.Api)

Provides the domain classes for the Biz.Api layer. These provide methods to manipulate the data of the business in memory.

  • /Dal.Db

(Referenced by Biz.Api)

The database repository layer. Accesses the databases and maps returned data into internal DTO's defined in the /Interfaces layer.

  • /Dal.Services

(Referenced by Biz.Api)

Provides a proxy layer to external dependencies like web services and maps their returned data to internal DTOs defined in the /Interfaces project.

  • /Interfaces

(Referenced by most projects above)

Contains the DTO classes for passing data around the solution and the C# interfaces to define contracts for things like IoC.

  • "/Biz.Api Provides the domain services" : do you mean Application Services ? Also, Repositories typically don't return DTOs but entities (aggregate roots). And dependencies between these projects would be good to know too ;) – guillaume31 Sep 10 '14 at 15:32
  • Yes, I mean App Services. The repositories are returning instances of classes which do nothing but store data - this data is mapped into the instance using, in this case, AutoMapper. The instance returned has no manipulating methods, which I gather Entities do have. – Matt W Sep 10 '14 at 16:09
  • "this data is mapped" : between what and what ? What do you mean by "manipulating methods" ? – guillaume31 Sep 11 '14 at 9:45
21

This folder structure is inspired by the famous Implementing domain driven design book by Vaugh Vernon.

Solution:
├ WebService (REST Services reside here)
├ WebServiceTests
├ Application (Application services reside here)
├ ApplicationTests
├ Domain (Entities, VO, Domain services, domain factories, specifications, domain events, Repositories interfaces, infrastructures services interfaces)
├ DomainTests
├ Infrastructure (Repositories, Infrastructure services impl., Adapters to external services)
└ InfrastructureTests

I start with a Solution then create four projects for each layer in my application then another four projects for each layer tests.

Don't create a folder interfaces or services in your domain layer instead related classes should be grouped by functionality in modules.

1

As far as the structure, it seems OK to me although I would have come up with different, more self-descriptive names, such as "YourProjectWebApi" instead of "Base", "Dal.External" instead of "Dal.Services" and so on.

There might be a smell in the "internal DTO" part though, as you're supposed to get entities out of repositories and be able to take domain (business) actions directly on them. Entities are not just DTO's.

I kind of gather from the fact that Dal.Db has no dependency to Biz.Domain, that the Domain layer is doing some mapping between DTO's from the Interfaces project (returned by Repositories ?) and its own Domain objects. This wouldn't be correct in a typical state-of-the-art (== "onion" or "hexagonal") DDD architecture -- the Domain layer shouldn't reference other projects. For the same reason, Repository interfaces should be declared in the Domain and not in Interfaces as I guess they are.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.