Application Logic or Orchestration Logic in OCH Architecture ?

Application Logic, Orchestration Logic, Workflow Logic, 

What is Orchestration Logic in OCH Architecture ?

Calling the different CustomerRepository, GenericRepository, CCCs Service, Third Party Services, GateWays, Other Applications, Email, OS Services is called the ORCHESTRATION LOGIC. This logic is done inside the Application Serivce. Command and Queries Application Services.

Low Level API are defined inside the Data Project, CCCs Project, Infrastructure Project, These APIs are called inside the Application Services. 

If the Request Processing is Complex and involve many components, then Application Service Method is Heavy and Application Service seems justified. 

If the Request Processing is Simple and involve one or two components, then Application Service Method is very light and Application Service seems un justified. But still for better seperation of Concerns we need to have it

Entity/Value Object hold the Single Entity Level Domain Logic. Entity Specific Domain Logic. Low Level Domain Logic. It has nothing to do with the Persistence Logic. In-Memory Domain Logic that is not related to Data Access or Data Save to the DB

Domain Service holds the Domain Logic related to Multiple Domain Entities/VO. In-Memory Domain Logic that is not related to Data Access or Data Save to the DB.

In OCH Arch, we hydrate the Single Record Domain Obj from the RequestModel

RequestModel ==> Entity/Domain Obj

After Hydrating, we can call different Methods of Entity to check whether the Entity obj is valid or not. 

We execute the Domain Logic to check whether the Domain Obj is valid or not.

In OCH Arch, Application Services/Commands calls the Repositories to do the job.

In case of Command App. Service, Orchestration Logic could be int he form


if (entityObj.DomainLogic())
entityRepository.Save(entityObj);


if (domainService(domainObj))
entityRepository.Save(domainObj)


Application Services/Command ==> Repository (Entity)


Above Orchestration Logic could be put inside the CustomRepository Class, inside the Data Project. Application Service Just Call the CustomRepository method and get things done.

Mixture of DB Oriented Logic, Domain Logic and Third Party Integration, External System Calls, CCCs Logic
Heavy Weight Application/Orchestration Logic
Heavy DB & Domain Orchestration Logic

If Orchestration Logic is the mixture of DB Oriented Logic, Domain Logic and Third Party Integration, External System Calls, CCCs Logic. In this case too, DB + Domain Oriented Logic should be Pushed to Custom Repository. Rest of the Logic is there in the Command Application Service. Command Application Service Method is Heavy in this case. CCC logic and High Level Application Logic like Logging, Exception Handling, Security, Auth, Auth is done inside the Application Service.

Class Command Application Service ()
{
// Complex Application Logic
=============
=============
==============
customRepository.Save(domainObj)
=============
=============

==============
} 

Class CustomRepository
{
   Save()
   {
          if (entityObj.DomainLogic())
          entityRepository.Save(entityObj);
          if (domainService(domainObj))

          entityRepository.Save(domainObj)
    }


}

DB Oriented + Domain Logic Oriented
Medium Level Application/Orchestration  Logic
Medium Level DB & Domain Orchestration Logic

If the Orchestration Logic is totally DB Oriented and Domain Logic Oriented, Such Orchestration Logic could be encapsulated  in the CustomRepository. Command Application Service Method is very light and it just Delegate Call to the CustomerRepository to do the job. Rest of the CCC logic and High Leve Application Logic like Logging, Exception Handling, Security, Auth, Auth is done inside the Application Service.

Class Command Application Service ()
{
// Light Application Logic
==============
customRepository.Save(domainObj)
=============
} 

Class CustomRepository
{
   Save()
   {
          if (entityObj.DomainLogic())
          entityRepository.Save(entityObj);
          if (domainService(domainObj))

          entityRepository.Save(domainObj)
    }
}


CRUD/Simple Domain/Forms-Over-Data
Very Light Application/Orchestration  Logic
No DB & Domain Orchestration Logic


In case of CRUD/Simple Domain/Forms-Over-Data, there is no Domain Logic. In this case, Application Service Method is very light. Just Delegate Calls to the Data Layer. There is no CustomRepository in case of CRUD. We use Generic Repository in case of CRUD. This Generic Repository instance is Created inside the Command Application Service.


Class Command Application Service ()
{
// No Application Logic
GenericRepository.Save(domainObj)

} 

Class GenericRepository<T>
{

      Browse<T> ();
      Read<T>();
       Edit<T>();
       Add<T>
       Delete<T>();

}