Skip to main content

Proximity to Domain-Knowledge Holders

Context​

Microservices are being adopted. The application domain of the overall system is complex. The domain knowledge holders are separate entities, like an organizational unit or an external customer.

Problem​

  • Information between domain knowledge holders and microservice teams is not flowing well
    • e.g., load spikes caused by a commercial campaign is detected as DoS (denial of service) attack.
    • For alternative paths in use cases are invented by the developers but don't meet the needs of the domain

Solution​

Bring the domain knowledge holders closer to the microservice teams.

Even without any change, the functional decomposition and the visibility of the responsible autonomous teams contributes to easier communication. Domain knowledge holders can identify the right contact person much easier and practice direct communication. However, in the other direction, the information flow between microservice teams and domain knowledge holders has to be established and practiced actively as well.

This can be facilitated by organizationally moving the domain holders closer to the team and involving them into the development life cycle. On the upper end, this means including them into the cross-functional team. For in-house products, this might mean practicing BizDevOps. You can also act the other way around and move the microservice team into the corresponding business organizational unit, for example would the group of microservices related to billing be governed and managed by the organizational unit associated with the billing processes and activities.

The shorter communication pathways lead to a better common understanding of the domain, a better alignment of the software to the user needs, and contributes to a higher release frequency.

Maturity​

Proposed, requires evaluation.

Sources of Evidence​

L16:

  • cites Newman to do domain driven design
    • Domain experts included more closely into loop of software engineering

L32:

  • Point "Shorter communication path from customers to the responsible developers" under "Shorter Cycle Time for Small Incremental Functional Changes"
  • shorter than with monolith
  • direct communication with responsible microservice person instead of the system responsible
  • probably because higher visibility - by autonomous team
  • shorter communication path shortens cycle time

L42:

  • Challenges in transition to microservices
  • bringing domain experts into the process of designing the new system is not a big challenge

L46:

  • business functional domain as "container" for microservices
    • e.g. microservices supporting billing functions managed & governed by unit associated with billing processes and activities

LM43:

  • Context: SLR findings about microservices in DevOps
  • Organizational problems related to culture, peopls, cost, organization, and team structure
  • Among others, providing separate physical locations to teams

Interview B:

  • Domain alternatives => need for a domain expert contact person
  • Best case: domain expert within team
  • Classical departments (customer, bank account, loan, ...) should be disbanded to get them closer to the developers
  • Example: Spotify
    • domain expert very close to developers
  • Feels unfamiliar when coming from classical enterprise development
  • (+) Leads to better alignment to what domain experts need

Interview C:

  • Need for domain knowledge: eventual consistency
  • BizDevOps: need the business people for the business/domain logic
  • Because IT automates business process => does a rollback make sense? or ...
    • dev and ops can't decide these things
  • Example: Otto had some TV commercial => load spike => ops: DoS attack!
    • BizDevOps fosters communication in these cases
    • Everyone reacted correctly from their local perspective
    • But need the communication

Interview F:

  • Context: do you need to move roles into microservice teams? E.g. ops, security, business knowledge
  • Not sure about business knowledge, they didn't have as complicated cases
  • only thing that required special knowledge was team with the data treasury
    • whole value of project was put into that one team
    • the rest was around that to make it accessible and usable
  • Affirms domain knowledge came into team via PO