In this post, I aim to shed light on the concept of "service hell" and offer strategies for circumventing such predicaments, emphasizing the critical role of service categorization for enhanced code hygiene.

What is "Service Hell"?

"Service Hell" describes a scenario in which an application is burdened by an overabundance of services, often characterized by vague responsibilities. This clutter leads to code that is challenging to comprehend, maintain, and expand. A lack of structured organization can result in repeated logic across services, undermining the principle of reusability.

Solutions to Navigate Away from "Service Hell"

1. Refine the Definition of "Service"

In contemporary development practices, any component that isn't an entity, repository, or a point of exposure (such as REST Controllers, GraphQL entry points, Kafka consumers, etc.) is often labeled as a service. However, this broad definition of service can be more usefully segmented into distinct categories:

• Application Service: Acts as the functional gateway of our application, orchestrating and coordinating all internal components to fulfill the requested action.
• Infrastructure Service: Expands our system's capabilities by interfacing with external components (e.g., HTTP clients to other microservices, email dispatching, etc.).
• Domain Service: Augments our business model with additional functionalities that necessitate computations beyond the capabilities of the business object itself (e.g., calculating an exchange rate for an order).

Over time, the essence of what constitutes a Service, as discussed by Martin Fowler, seems to have been diluted.

2. Enhance Service Cohesion

It's crucial to ensure that each service class is assigned a clear and consistent responsibility. Adhering to the Single Responsibility Principle is advisable here.

3. Assess Service Granularity

The granularity of your services warrants careful consideration. Services that are either too granular or too bulky can pose issues. Striking a balance that aligns with your application's size and complexity is key.

4. Improve Organizational Structure for Clarity

Services should be organized in a manner that mirrors the business domain of your application. This organization might involve categorizing services by functionality, domain, or other logical divisions, facilitating a more intuitive understanding.

Your Thoughts?

This introduction serves as a starting point for further discussion on this topic. I welcome your insights and questions in the comments below.