Service Oriented Architecture

Application with single transactional resource:

Architecture: Common Approach most developers used is create a controller and relevant model. All business logics will resides in controller and controller requests to model.      

Controller in MVC : 

The role of a controller, in MVC, is to orchestrate the process:

1. Get the relevant input from the request,
2. Delegate to validators the task of validating/sanitizing the input,
3. Call the relevant methods of business layer,
4. Give to MVC framework the resulting model and the view.

The role of a controller is not to deal with business logic.

By writing business logics in controller, we spoil its nature.

Another point is that every code snippet has a purpose and implements a specific behavior. Sometimes that purpose and behavior are highly reusable. If we write business logics in controller, we can not reuse business logic anymore if needed.

We should place Business Logics in a separate file : 

A Helper class can not be a Business layer :

we should not write business logics in helper class as purpose of helper class is to contain only pure functions, not to communicate with Model/Data Layer. For example: haversine formula or calculate number of days between two days etc.

While writing business logics, if we need any common function for data manipulation like haversine formula or calculate number of days between two days, we can write this type of functions in helper and can call in business layer.

Application with multiple transactional resources : 

Why we repeat common business logics for API & Web at both end. Alternatively we can write business logics at API end and serve to both Web & App.

SOA is an architectural pattern. A service-oriented architecture is essentially a collection of services. These services communicates with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity.

Why SOA :

There are many factors that go into the decision of creating a service layer. I have created service layers in the past for the following reasons.

1. Code that needs to be re-used by multiple clients/sources.
2. Third party libraries that we have limited licenses for.
3. Centralizing duplicated business logic.
4. Reduce maintenance costs.
5. Loose Coupling.

Cons :

Everything we do has a result. Here are also some cons of SOA.

1. Adds system complexity
2. One point of failure
3. Versioning can be harder to do