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?