MF ABP Framework about Application Service Layer

Application Service Layer or Service Layer

There is not strict Layering in the Application Service Layer. 

It can call any infrastructure code in lower layers or in external Libraries, CCCs, Infrastructure. Reposistory/Data project

All Domain Services (Part of Domain Model in DDD) those depend upon Technical Infrastructure Code, should reside in Application Service Layer. 

Their implementation live in Application Service Layer but their interface live in Domain Model project. These are impure Domain Services. 

Pure Domain Services totally live inside the Domain Model

In ABP, we have Distributed Service Layer, which is the Controller Layer  or Web API Controller in ASP.NET MVC

Object Orchestration can be done in three places 

• App. Services holding Usecase leve Application Logic 
• Domain Services holding Domain Logic 
• Aggregates Entities holding Domain Logic

App. Service may involve the Simple Call to the Domain Layer or Complex Orchestrated Call to the Domain Layer

App. Services has to deal with the other CCCs of the EA. 

Domain Model should be pure and crystal OO API encasualting the Domain Logic

All Junk CCCs are done in the App. Service

All Domain Services those depend upon the Infrastructure code are put inside the App. Service Layer.

So there are two types of Domain Services, 

1) Pure Domain Services, those do not depend on the Infrastructure, and their Interface and Implementation resides in the Domain Layer. 

2) Hybrid Domain Services, those depend upon the Infrastructure and their Interface reside inside the Domain Layer and Implementation reside inside the Service Layer.

App. Service deals with the Infrastructure and CCCs, those help in Executing the Domain Layer Correctly. 

Application Services Provide the Environment in which Domain Layer works perfectly.

Hybrid Domain Services in the Service Layer deals with the Infrastructure Code to fetch some Data and Inform the Domain Layer. Like making a Web Call to fetch the Weather information from the Web.

Hybrid Domain Services fulfills the Data Needs of the Domain Layer. Like fetching Data from Http. Somtimes Domain Model is needed to be hydrated from the Http Web Calls rather than the DB. 

Domain Model can be hyderated from the DB and Web Services 

Application Service Layer has two types of Services, 
1) App. Services e.g. Command and Queries 2) Hybrid Domain Services

Domain Services can live in two layers, App. Service Layer and Domain Layer.

According to MF Book, the Application Service Layer is optional. That means for CRUD domains it can be avoided. 

But in OCH Arch, or in Jimmy Bogard Vertical Slice Architecture, Application Service Layer is mandatory.

AS Layer is only applicable when we use the Domain Model Pattern and our Domain is reasonably Complex.

AS Layer is needed when the Business Logic is complex enough and we split it into two types of logic, 

High level Application Logic centered around use cases consist of high level calls to Domain Model, Persistence, Infrastructure and CCSs.

Other logic involve Domain Logic. 

Orchestration or calling the different CCCs services like

Authentication, Authorization, Exception Management, Logging & Instrumentation, Audit Trail. Auto Mapping, Object Mapper, Background Jobs, Email Sending, Messaging & Queue, calling the Domain Objects in the Domain Model is the responsibility of Application Layer.

Calling the Domain Logic

Calling the CCCs logic and they are many.

When there is no CCCs logic or very little CCCs logic, it excessive to have Application Service Layer. But in OCHV architecture it is mandatory. 

Martin Fowler about the Application Logic and Service Layer

As well as providing a clear API, the Application Service Layer (133) is also a good spot to place such things as transaction control and security.

Transactional and security characteristics

The minimal case is to make the Application Service Layer (133) a facade so that all of the low level domain behavior is in underlying Domain Layer objects and all the Service Layer (133) does is forward calls on the facade to lower-level Domain Layer objects. 

In that case the Service Layer (133) provides an API that's easier to use because it's typically oriented around use cases. 

It also makes a convenient point for adding transactional wrappers and security checks.

I use the term use-case controller. Behavior that's used in more than one use case goes on the domain objects, which are called entities.

MF books is quite quiet about the Domain Model. it only highlights the Entities. it is the DDD communit that dig deep into the code of enterprise application and find detailed level patterns. these pattern were further implemented in diff techlogies, frameworks, orms and we further find the implementation patterns. One DDD pattern has many Implementations or Variations those tell how to realize them in Code.

My preference is thus to have the thinnest Service Layer (133) you can, if you even need one. 

My usual approach is to assume that I don't need one and only add it if it seems that the application needs it. 

However, I know many good designers who always use a Service Layer (133) with a fair bit of logic, so feel free to ignore me on this one. 

Randy Stafford has had a lot of success with a rich Service Layer (133), which is why I asked him to write the Service Layer (133) pattern for this book.