.NET MVC 5 and Onion Architecture

Question

I'm writing big project and I want to apply Domain Driven Design (DDD) on it. Here is my projects and explanation:

XXX.Domain.Entities - POCO (Plain Old C# Object) classes (Ex: Message.cs)
XXX.Domain.Services - The services of the domain
XXX.Infrastructure - Infrastructure Interfaces
XXX.Infrastructure.Concrete - the impl of the intefaces from XXX.Infrastructure
XXX.Infrastructure.DI - Dependency injection modules (Ex: RepositoryModule.cs)
XXX.Services - The services of the application (but I don't know where to put the impl)
XXX.Tests - Unit tests (Ex: SomeTest.cs)
XXX.Web.Ui - MVC5 app

But I can't understand where I should put anyone of those: IMessagesService.cs (BL for model Messages), MessagesService.cs (BL for model Messages), SessionHelper.cs, MessageMapping.cs, IMailerService.cs, MailerService.cs

Also: Where should I put IRepository and GenericRepository (impl)?

Similiar with http://stackoverflow.com/questions/18166740/what-are-the-typical-layers-in-an-onion-architecture/18168046#18168046 — Yugang Zhou, Jan 07 '14 at 23:23

Ilya Palkin · Accepted Answer · 2014-01-08T22:45:26.670

1

You can simply put all implementations into folder Impl within XXX.Services project, if you want to organise your Application Services. There is an option you have instead of creation of new project for implementations only.

enter image description here

But SessionHelper and MessageMapping look like DataAccess specific infrastructure and should be put close to your data access components.

Also, I would put all domain entities and domain services into single project Domain Model. In this case your domain logic won't be split between two projects, XXX.Domain.Entities and XXX.Domain.Services so that all your domain logic will grouped.

EDIT :

There is a good list of differences between domain service and an application services in the post "Services in Domain-Driven Design (DDD)":

Domain services are very granular where as application services are a facade purposed with providing an API.

Domain services contain domain logic that can’t naturally be placed in an entity or value object whereas application services orchestrate the execution of domain logic and don’t themselves implement any domain logic.

Domain service methods can have other domain elements as operands and return values whereas application services operate upon trivial operands such as identity values and primitive data structures.

Application services declare dependencies on infrastructural services required to execute domain logic.

Command handlers are a flavor of application services which focus on handling a single command typically in a CQRS architecture.

edited Jan 08 '14 at 22:45

answered Jan 07 '14 at 22:37

Ilya Palkin

14,687
2
23
36

And where should I put IMailerService and MailerService (impl)? – Zilberman Rafael Jan 08 '14 at 06:30
Usually `MailerService'/`IMailerService` is part of Application Services. But, if it is needed to have an access to `IMailerService` in Domain Model you can create another one project (e.g. Core) with core interfaces and refer to it from other projects. – Ilya Palkin Jan 08 '14 at 07:36
So what projext should I put MailerService in? – Zilberman Rafael Jan 08 '14 at 08:17
Let's say `XXX.Services` – Ilya Palkin Jan 08 '14 at 08:40
So the application services should be in XXX.Services and domain logic in XXX.Domain.Services? – Zilberman Rafael Jan 08 '14 at 09:05
Yes, application services should be in `XXX.Services`. But I wouldn't split domain logic into `XXX.Domain.Entities` and `XXX.Domain.Services` since Domain Services is just "contain domain logic that can’t naturally be placed in an entity". – Ilya Palkin Jan 08 '14 at 22:38

.NET MVC 5 and Onion Architecture

1 Answers1