The God Object

Description

A service that provides a large number of operations for multiple different business and technical abstractions. Often has a bloated interface and implementation.

Context

Derived from: “The God Object”

Cause

Hidden or unclear requirements may make it difficult to identify fitting abstractions. Wrongly applied patterns may also lead to a megaservice. The service designer may also be unfamiliar with the principles of high cohesion and low coupling.

Consequences

Having only a few or even a single large service within the system may impact maintainability, performance, and availability. A very large service is harder to analyze and comprehend. Furthermore, multiple developers will concurrently work on the same service, which can cause unnecessary conflicts. Such a service will also have many consumers and therefore increases coupling in the system. Any changes to its interface result in ripples to these consumers. Moreover, testing such a service becomes very time consuming due to the dependencies within the service. The size and complexity of the service can also mean that using the service needs special effort. Lastly, such a service may become a performance bottleneck or a single point of failure.

Detection

The service possesses a variety of public interface operations that are related to different domains or entities. We consider an Application Component that implements multiple functions exposed by a single application service.

Solution

The megaservice should be decomposed into several smaller services. The service’s inappropriate features need to be extracted to new components.

Example

A service that implements operations from different domains.

Cypher query

MATCH (c)-[r2:RealizationRelationship]-(s:ApplicationInterface|ApplicationService) <br /> WITH c, COUNT(s) AS exposedServiceCnt <br /> WHERE exposedServiceCnt=1 <br /> WITH c <br /> MATCH (c)-[r:RealizationRelationship]-(n) <br /> WITH c, COUNT(n) AS functionsCnt <br /> MATCH p= (c)-[r:RealizationRelationship]-(n)  <br /> WHERE functionsCnt > $functionOrServiceCnt <br /> RETURN p

Cypher count query

MATCH (c)-[r2:RealizationRelationship]-(s:ApplicationInterface|ApplicationService) <br /> WITH c, COUNT(s) AS exposedServiceCnt <br /> WHERE exposedServiceCnt=1 <br /> WITH c <br /> MATCH (c)-[r:RealizationRelationship]-(n) <br /> WITH c, COUNT(n) AS functionsCnt <br /> MATCH p= (c)-[r:RealizationRelationship]-(n)  <br /> WHERE functionsCnt > $functionOrServiceCnt <br /> RETURN COUNT (distinct c)

Diagram

Aliases

Megaservice, Swiss Army Knife, Bloated Service

Tags

microservices, soa, business, application, technology, cohesion, abstraction, The Bloaters, The Couplers, within elements

Query parameters

[
    {
        "name": "functionOrServiceCnt",
        "type": "number",
        "default": 3,
        "description": "The permitted number of functions implemented by an application component."
    }
]

Related smells

• Multifaceted Abstraction (relates)
• Bloated Service (relates)

All smells