DDD Projects Structure With WCF

Question

I\'m starting a new WCF-based project which is composed by an \"Engine\" and some desktop applications. But i found it difficult to make my project structure.

• Engi

Answer 1

If you are doing DDD I find it strange that you have no domain model. You have a so-called engine, which has multiple concerns. It implements your business logic and knows about hosting your business logic as a windows service.

I would propose a project structure as follows:

MyProject.Model: Defines abstract repositories, entities, value objects, services (DDD term) and other domain logic. It has no references to other projects

MyProject.DataAccess: implementation of repositories using linq2sql. Has a reference to MyProject.Model

MyProject.ServiceModel: Contains service contracts and other stuff related exposing your domain model as WCF services. this project would also contain service specific representations of those of your domain objects that the service serves and accepts. The reason for this would be that you should probably not decorate your domain classes with the attributes needed in WCF data contracts. This project references MyProject.Model.

MyProject.Service: Contains app.config for your service and performs dependency injection, through a custom ServiceHost and ServiceHostFactory. It references MyProject.Model MyProject.ServiceModel and MyProject.DataAccess + your favorite DI framework (Windsor Castle for example)

MyProject.PresentationModel: Defines various view models and commands to use in your UI. It has service references to the services exposed by MyProject.Service

MyProject.WinUI: Your WPF app. References MyProject.PresentationModel.

Note that most of what you have probably read in Eric Evans' book about DDD is only concerned with the contents of MyProject.Model. The other projects are making up additional layers not directly addressed in mr. Evans' book.

Remember that by having a clear separation of concerns, and using dependency injection you will end up with code that is easily tested. With the structure I have proposed above, you should be able to test almost everything, since your UI will contain only XAML.

Anyway, this is just my take on it. Please feel free to ask if some of this needs clarification.

Good luck with the project.

/Klaus