Why don't we put business logic in the services? Will we ever replace our services?

Question

I am developing a system, and I have read many articles that do not say that business logic does not enter service code. And just put your business logic in your domain objects.

I do not place my service code anywhere, and my presentation level accesses it directly. In the future, I might want to expose this service code through the IIS WCF service.

But I do not understand why services should be easy? What is its advantage? When will we ever replace our services? Please explain

Answer 1

The idea is that, having different layers in his application, he makes it reusable. For example, your business layer might have a feature for checking books. Well, you can take this function and call it from different layers. A Console application can call it, a service can call it, or a web page can call it.

In addition, it is easier to test. You can call the method in an example application that just calls your BLL, and you don’t have to worry about your service calling it.

Answer 2

In my understanding, it is about observing the principle of single responsibility. The general idea is that the only responsibility of your level of service should be the transfer of service operations to domain operations. That is, you write a type of service that provides a method that represents a service operation with a service contract as an input. A service method converts a maintenance operation into a domain operation and allows the domain object (s) to worry about business rules. Thus, your type encapsulates the translation of a service operation into a domain operation and nothing more.

Please note that I assume that the “service” code in the articles you link to refers to the service interface in a service-oriented architecture .