Services and Authorization in Onion Architecture

Question

I'm trying to learn Onion Architecture and as i understand, I've organized my solution as follows:

Domain

• Domain.Entities (Business objects)
• Domain.Interfaces (Interfaces for domain services and repositories)
• Domain.Services (Implementation for domain services interfaces)

Infrastructure

• Infrastructure.Data (Implementation for repositories and unit of work with EF)
• Infrastructure.DependencyResolution (Implementation for IoC with Unity)

UI

• UI.WebMVC

And here are my questions:

1- Am i right with these layers or i'm missing something ?

2- As for services that are related to a specific technology (e.g. Logging), where their interfaces should be (Domain.Interfaces or Infrastructure.Interfaces) ?

3- As i understand, The Domain Service will process my business use case so what are the benefits i'll get from application service

4- What are the differences between Domain Service and Application Service and in which project Application Service interfaces should be?

5- Should User Authorization process be a part of Application Services or Domain Services?

Propst

Answer 1

1. This a schema of hexagonal architecture, but it's really close to onion and IMO you should use that. Here are shown 3 layers: domain (yellow), application (red), infrastructure (green + blue). So answering your question - you are missing few pieces like application services.

2. Logging is probably not part of your domain logic, so it should be in infrastructure, both interface and implementation. To use it, you have to inject it to your application layer.

3. Domain services are taking care only of things that are related to your businness. Application services are most of the time preparing ground for domain services, in example creating repositories and retrieving aggregates from it, then calling domain services and passing that aggregates there. You shouldn't handle your business logic in app layer!

4. As I wrote in point 3. Application services should be in every projects that are using domain services.

5. Depends. User request your infrastructure layer with user credentials, infrastructure layer calls application layer with that credentials, there you try to retrieve user with given credentials, but first you convert raw password to hashed one with some functions. If user is found, you can authenticate user in infrastructure layer. Domain service wasn't needed here, but it's an exception.

Borrowing

Thanks for your reply Rafal, I'm confused right now, 1- Should application services be in a separate project(dll) or in each project that uses domain services in the solution? 2- In your example about application services, you said that they are creating repositories and retreiving aggregates from it to be passed to the domain service, Why i do so in the application service while i've full access to repositories from domain service ? – Propst

1. Application services are handling domain services, you shouldn't handle domain service directly from infrastructure (in example from framework controller/view). 2. Because in domain layer you do only business logic. Retrieving aggregates is not a business logic. You should learn DDD by Evans, or at least IDDD by Vernon. – Conditional

Thanks Rafal, I think things are beginning to be more clear to me – Propst