Skip to main content

Group Services Based on Domain Proximity

Context​

Microservices are being adopted. Each microservice is assigned to exactly one team. There is still need for coordination between microservices and their respective teams The number of microservices is comparatively high.

Problem​

  • Coordination need between microservice teams causes communication overhead and decreases the innovation speed

Solution​

Group services based on their functional proximity and assign them to teams that are organizationally aligned very closely.

When two teams are organizationally aligned closely (e.g. in the same department), chances are high that coordination is faster than coordinating with teams of other departments. The best case would be that the microservices that require coordination more often (because they are functionally close together) are allocated to the same team.

Building these groups and building hierarchies can also help to keep an overview over the large amount of microservices, for example for implementing differently grained security policies based on the different layers in the hierarchy.

Maturity​

Proposed, to be evaluated.

Sources of Evidence​

L14:

  • Otto.de used Conway's law
    • today 18 teams on 45 applications in 12 so-called "verticals"

L20:

  • Another gain of microservices: layered and fine-grained security policies
  • define hierarchical groupings of microservices
    • designers can apply differently grained security policies to different layers in hierarchy

L45:

  • Cluster = group microservices under specific characteristic
    • => logical division of system into groups
  • hierarchical grouping of microservices => security policies differently grained to the different layers in a hierarchy

L46:

  • Microservices = fine-grained building blocks;
  • Microservice domain = logical business entity containing collection of related microservices of the domain
    • assist to manage microservices of the domain
    • proliferation of microservices and consequences: multiple data models, platform and technology, cross-dependencies to other microservices
  • business functional domain as "container" for microservices
    • e.g. microservices supporting billing functions managed & governed by unit associated with billing processes and activities

Interview A:

  • One team multiple microservices
  • communication effort within team most of the times
    • (=> interpretation: need to be grouped and assigned to team)

Interview B:

  • One team usually develops multiple microservices
    • functionally close together => contact persons close