Intro

Last time we built a strong foundation for our Blog based on the concepts of Clean Architecture. We set up rules and data structures of Article and Comment: primary building blocks of our app. In this post, we will take another step further: we are going to write Services.

What is a “Service”? Depending on the context and who you are talking with, you may receive completely different definitions and explanations. In our case, I will boldly name them as “something that performs core business operations.” From an architectural point of view, it’s the next circle in the dependency diagram.

From a technical perspective, it can be anything: class, function, a cluster of functions, and an object with methods. The only rule: keep it away from “details”: frameworks, stores, UI, etc. The only dependency Service should have are Entities or other Services.

From a conceptual point of view, the goal of services is to perform required business operations on Entities. If you are familiar with Uncle’s Bob book “Clean Architecture,” you may notice some deviation. In his book, Bob Martin described the next circle as “use cases.” I am not reinventing the wheel but combine use cases under the umbrella of “service(s).” If you are familiar with the Repository-Service pattern, which is quite popular in the backend world, you may find a lot of similarities.