Domain-Motivated Implementation Details

Context

Microservices are being adopted. Communication between microservices happens over an unreliable network using a messaging mechanism. Technical error handling mechanisms are implemented, like timeouts, retries or dead letter queues.

Problem

• Technical motivated specifics of the error handling leads to unsatisfying behavior.

Solution

Base technical error handling mechanisms on domain knowledge.

For example, a sequential message queue processing mechanism should be based on the need for such strict message ordering. Sequential processing implicates that unprocessable messages might lead to a blocked queue. This slows down the whole system and makes it prone to failures. Thus, this design decision including the technical error handling (in this example: blocking until resolved) should be motivated by domain knowledge. If the need for message ordering is not required by a specific use-case, removing the blocking message and processing it on the side is the better solution.

Incorporating domain knowledge next to the technical knowledge can be a challenge for developers.

Maturity

More data required (only 1 source).

Sources of Evidence

Interview B:

• Dead-letter queues: requires timeout
  • timeout needs to be motivated by domain knowledge
  • random values like 10min, 10sec, 3sec don't help
  • needs to be specific to use-case
• is a huge challenge for many devs coming from enterprise computing
  • what makes sense from domain perspective
  • not solely focused on technical perspective
• Example: automotive context
  • order of messages important in one use-case, for other use-cases not important
  • but queue implemented to be worked on sequentially
    • one element can't be processed => blocks queue
    • makes no sense from domain perspective
    • what would have make sense: take the blocking one, put it to the side and deal with it
    • but wanted to take the "safe" route => system became slow and prone to failures