Service Granularity

Granularity Disintegrators

Granularity disintegrators provide guidance and justification for when to break a service into smaller parts. While the justification for breaking up service may involve only a single driver, in most cases the justification will be based on multiple drivers.

• Service scope and function: is the service doing too many unrelated things?

• Code volatility: Are changes isolated to only one part of the service?

• Scalability and throughput: Do parts of the service need to scale differently?

• Fault tolerance: Are there errors that cause critical functions to fail within the service?

• Security: Do some parts of the service need higher security levels than others?

• Extensibility: Is the service always expanding to add new contexts?

Granularity integrators

• Database transactions: Is an ACID transaction required between separate services?

• Workflow and choreography: Do services need to talk to one another?

• Shared code: Do services need to share code among one another?

• Database relationship: Although service can be broken apart, can the data it uses be broken apart as well?